git/builtin/get-tar-commit-id.c, branch v2.32.2

builtin/get-tar-commit-id: make hash size independent

2019-04-01T02:57:39Z

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

get-tar-commit-id: parse comment record

2019-04-01T02:57:39Z

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

distinguish error versus short read from read_in_full()

2017-09-27T06:45:24Z

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

prefer "!=" when checking read_in_full() result

2017-09-27T06:45:24Z

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

get-tar-commit-id: check write_in_full() return against 0

2017-09-14T06:16:21Z

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

usage: do not insist that standard input must come from a file

2015-10-16T22:27:52Z

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] < 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] < > * As it is our convention to enclose placeholders inside , 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

use skip_prefix() to avoid more magic numbers

2014-10-07T18:09:16Z

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

stop installing git-tar-tree link

2013-12-03T20:35:22Z

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