path: root/builtin/get-tar-commit-id.c
AgeCommit message (Collapse)Author
2019-04-01builtin/get-tar-commit-id: make hash size independentbrian m. carlson
To make this code independent of the hash size, verify that the length of the comment is equal to that of any supported hash algorithm. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2019-04-01get-tar-commit-id: parse comment recordRene Scharfe
Parse pax comment records properly and get rid of magic numbers for acceptable comment length. This simplifies a later change to handle longer hashes. Signed-off-by: Rene Scharfe <> Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2017-09-27distinguish error versus short read from read_in_full()Jeff King
Many callers of read_in_full() expect to see the exact number of bytes requested, but their error handling lumps together true read errors and short reads due to unexpected EOF. We can give more specific error messages by separating these cases (showing errno when appropriate, and otherwise describing the short read). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-09-27prefer "!=" when checking read_in_full() resultJeff King
Comparing the result of read_in_full() using less-than is potentially dangerous, as a negative return value may be converted to an unsigned type and be considered a success. This is discussed further in 561598cfcf (read_pack_header: handle signed/unsigned comparison in read result, 2017-09-13). Each of these instances is actually fine in practice: - in get-tar-commit-id, the HEADERSIZE macro expands to a signed integer. If it were switched to an unsigned type (e.g., a size_t), then it would be a bug. - the other two callers check for a short read only after handling a negative return separately. This is a fine practice, but we'd prefer to model "!=" as a general rule. So all of these cases can be considered cleanups and not actual bugfixes. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-09-14get-tar-commit-id: check write_in_full() return against 0Jeff King
We ask to write 41 bytes and make sure that the return value is at least 41. This is the same "dangerous" pattern that was fixed in the prior commit (wherein a negative return value is promoted to unsigned), though it is not dangerous here because our "41" is a constant, not an unsigned variable. But we should convert it anyway to avoid modeling a dangerous construct. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-10-16usage: do not insist that standard input must come from a fileJunio C Hamano
The synopsys text and the usage string of subcommands that read list of things from the standard input are often shown like this: git gostak [--distim] < <list-of-doshes> This is problematic in a number of ways: * The way to use these commands is more often to feed them the output from another command, not feed them from a file. * Manual pages outside Git, commands that operate on the data read from the standard input, e.g "sort", "grep", "sed", etc., are not described with such a "< redirection-from-file" in their synopsys text. Our doing so introduces inconsistency. * We do not insist on where the output should go, by saying git gostak [--distim] < <list-of-doshes> > <output> * As it is our convention to enclose placeholders inside <braket>, the redirection operator followed by a placeholder filename becomes very hard to read, both in the documentation and in the help text. Let's clean them all up, after making sure that the documentation clearly describes the modes that take information from the standard input and what kind of things are expected on the input. [jc: stole example for fmt-merge-msg from Jonathan] Helped-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2014-10-07use skip_prefix() to avoid more magic numbersRené Scharfe
Continue where ae021d87 (use skip_prefix to avoid magic numbers) left off and use skip_prefix() in more places for determining the lengths of prefix strings to avoid using dependent constants and other indirect methods. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2013-12-03stop installing git-tar-tree linkJonathan Nieder
When the built-in "git tar-tree" command (a thin wrapper around "git archive") was removed in 925ceccf (tar-tree: remove deprecated command, 2013-11-10), the build continued to install a non-functioning git-tar-tree command in gitexecdir by mistake: $ PATH=$(git --exec-path):$PATH $ git-tar-tree -h fatal: cannot handle tar-tree internally The list of links in gitexecdir is populated from BUILTIN_OBJS, which includes builtin/tar-tree.o to implement "git get-tar-commit-id". Rename the get-tar-commit-id source file to builtin/get-tar-commit-id.c to reflect its purpose and fix 'make install'. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>