aboutsummaryrefslogtreecommitdiff
path: root/builtin/get-tar-commit-id.c
Commit message (Collapse)AuthorAge
* distinguish error versus short read from read_in_full()Jeff King2017-09-27
| | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* prefer "!=" when checking read_in_full() resultJeff King2017-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* get-tar-commit-id: check write_in_full() return against 0Jeff King2017-09-14
| | | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* usage: do not insist that standard input must come from a fileJunio C Hamano2015-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* use skip_prefix() to avoid more magic numbersRené Scharfe2014-10-07
| | | | | | | | | 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 <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* stop installing git-tar-tree linkJonathan Nieder2013-12-03
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 <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>