summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2016-06-13blame,shortlog: don't make local option variables staticLibravatar Jeff King2-9/+9
There's no need for these option variables to be static, except that they are referenced by the options array itself, which is static. But having all of this static is simply unnecessary and confusing (and inconsistent with most other commands, which either use a static global option list or a true function-local one). Note that in some cases we may need to actually initialize the variables (since we cannot rely on BSS to do so). This is a net improvement to readability, though, as we can use the more verbose initializers for our string_lists. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-13interpret-trailers: don't duplicate option stringsLibravatar Jeff King1-1/+1
There's no need to do so; the argv strings will last until the end of the program. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-17Merge branch 'maint-2.5' into maint-2.6Libravatar Junio C Hamano2-21/+6
* maint-2.5: Git 2.5.5 Git 2.4.11 list-objects: pass full pathname to callbacks list-objects: drop name_path entirely list-objects: convert name_path to a strbuf show_object_with_name: simplify by using path_name() http-push: stop using name_path tree-diff: catch integer overflow in combine_diff_path allocation add helpers for detecting size_t overflow
2016-03-17Merge branch 'maint-2.4' into maint-2.5Libravatar Junio C Hamano2-21/+6
* maint-2.4: Git 2.4.11 list-objects: pass full pathname to callbacks list-objects: drop name_path entirely list-objects: convert name_path to a strbuf show_object_with_name: simplify by using path_name() http-push: stop using name_path tree-diff: catch integer overflow in combine_diff_path allocation add helpers for detecting size_t overflow
2016-03-16list-objects: pass full pathname to callbacksLibravatar Jeff King2-21/+6
When we find a blob at "a/b/c", we currently pass this to our show_object_fn callbacks as two components: "a/b/" and "c". Callbacks which want the full value then call path_name(), which concatenates the two. But this is an inefficient interface; the path is a strbuf, and we could simply append "c" to it temporarily, then roll back the length, without creating a new copy. So we could improve this by teaching the callsites of path_name() this trick (and there are only 3). But we can also notice that no callback actually cares about the broken-down representation, and simply pass each callback the full path "a/b/c" as a string. The callback code becomes even simpler, then, as we do not have to worry about freeing an allocated buffer, nor rolling back our modification to the strbuf. This is theoretically less efficient, as some callbacks would not bother to format the final path component. But in practice this is not measurable. Since we use the same strbuf over and over, our work to grow it is amortized, and we really only pay to memcpy a few bytes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-16list-objects: drop name_path entirelyLibravatar Jeff King2-4/+4
In the previous commit, we left name_path as a thin wrapper around a strbuf. This patch drops it entirely. As a result, every show_object_fn callback needs to be adjusted. However, none of their code needs to be changed at all, because the only use was to pass it to path_name(), which now handles the bare strbuf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-04Merge branch 'jk/symbolic-ref-maint' into maintLibravatar Junio C Hamano1-1/+1
"git symbolic-ref" forgot to report a failure with its exit status. * jk/symbolic-ref-maint: t1401: test reflog creation for git-symbolic-ref symbolic-ref: propagate error code from create_symref()
2015-12-21symbolic-ref: propagate error code from create_symref()Libravatar Jeff King1-1/+1
If create_symref() fails, git-symbolic-ref will still exit with code 0, and our caller has no idea that the command did nothing. This appears to have been broken since the beginning of time (e.g., it is not a regression where create_symref() stopped calling die() or something similar). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-11Merge branch 'rs/show-branch-argv-array' into maintLibravatar Junio C Hamano1-16/+8
Code simplification. * rs/show-branch-argv-array: show-branch: use argv_array for default arguments
2015-12-11Merge branch 'rs/pop-commit' into maintLibravatar Junio C Hamano5-37/+14
Code simplification. * rs/pop-commit: use pop_commit() for consuming the first entry of a struct commit_list
2015-12-04Merge branch 'dk/gc-idx-wo-pack' into maintLibravatar Junio C Hamano2-2/+45
Having a leftover .idx file without corresponding .pack file in the repository hurts performance; "git gc" learned to prune them. We may want to do the same for .bitmap (and notice but not prune .keep) without corresponding .pack, but that can be a separate topic. * dk/gc-idx-wo-pack: gc: remove garbage .idx files from pack dir t5304: test cleaning pack garbage prepare_packed_git(): refactor garbage reporting in pack directory
2015-11-16allow hooks to ignore their standard input streamLibravatar Clemens Buchacher1-0/+3
Since ec7dbd145 (receive-pack: allow hooks to ignore its standard input stream) the pre-receive and post-receive hooks ignore SIGPIPE. Do the same for the remaining hooks pre-push and post-rewrite, which read from standard input. The same arguments for ignoring SIGPIPE apply. Include test by Jeff King which checks that SIGPIPE does not cause pre-push hook failure. With the use of git update-ref --stdin it is fast enough to be enabled by default. Signed-off-by: Clemens Buchacher <clemens.buchacher@intel.com> Signed-off-by: Jeff King <peff@peff.net>
2015-11-05Merge branch 'js/misc-fixes' into maintLibravatar Junio C Hamano1-1/+1
Various compilation fixes and squelching of warnings. * js/misc-fixes: Correct fscanf formatting string for I64u values Silence GCC's "cast of pointer to integer of a different size" warning Squelch warning about an integer overflow
2015-11-05Merge branch 'jc/add-u-A-default-to-top' into maintLibravatar Junio C Hamano1-7/+1
"git --literal-pathspecs add -u/-A" without any command line argument misbehaved ever since Git 2.0. * jc/add-u-A-default-to-top: add: simplify -u/-A without pathspec
2015-11-05Merge branch 'nd/clone-linked-checkout' into maintLibravatar Junio C Hamano1-3/+10
It was not possible to use a repository-lookalike created by "git worktree add" as a local source of "git clone". * nd/clone-linked-checkout: clone: better error when --reference is a linked checkout clone: allow --local from a linked checkout enter_repo: allow .git files in strict mode enter_repo: avoid duplicating logic, use is_git_directory() instead t0002: add test for enter_repo(), non-strict mode path.c: delete an extra space
2015-11-04Merge branch 'es/worktree-add' into maintLibravatar Junio C Hamano1-1/+1
* es/worktree-add: worktree: usage: denote <branch> as optional with 'add'
2015-11-04gc: remove garbage .idx files from pack dirLibravatar Doug Kelly1-0/+21
Add a custom report_garbage handler to collect and remove garbage .idx files from the pack directory. Signed-off-by: Doug Kelly <dougk.ff7@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-03Merge branch 'mk/blame-error-message' into maintLibravatar Junio C Hamano1-1/+1
The error message from "git blame --contents --reverse" incorrectly talked about "--contents --children". * mk/blame-error-message: blame: fix option name in error message
2015-11-03Merge branch 'jk/merge-file-exit-code' into maintLibravatar Junio C Hamano1-0/+3
"git merge-file" tried to signal how many conflicts it found, which obviously would not work well when there are too many of them. * jk/merge-file-exit-code: merge-file: clamp exit code to maximum 127
2015-11-03Merge branch 'jc/am-3-fallback-regression-fix' into maintLibravatar Junio C Hamano1-16/+33
"git am -3" had a small regression where it is aborted in its error handling codepath when underlying merge-recursive failed in certain ways, as it assumed that the internal call to merge-recursive will never die, which is not the case (yet). * jc/am-3-fallback-regression-fix: am -3: do not let failed merge from completing the error codepath
2015-11-03Merge branch 'jc/usage-stdin' into maintLibravatar Junio C Hamano11-12/+12
The synopsis text and the usage string of subcommands that read list of things from the standard input are often shown as if they only take input from a file on a filesystem, which was misleading. * jc/usage-stdin: usage: do not insist that standard input must come from a file
2015-11-03Merge branch 'rt/placeholder-in-usage' into maintLibravatar Junio C Hamano1-2/+2
A couple of commands still showed "[options]" in their usage string to note where options should come on their command line, but we spell that "[<options>]" in most places these days. * rt/placeholder-in-usage: am, credential-cache: add angle brackets to usage string
2015-11-03Merge branch 'nd/gc-auto-background-fix' into maintLibravatar Junio C Hamano1-1/+55
When "git gc --auto" is backgrounded, its diagnosis message is lost. Save it to a file in $GIT_DIR and show it next time the "gc --auto" is run. * nd/gc-auto-background-fix: gc: save log from daemonized gc --auto and print it next time
2015-11-03Merge branch 'js/clone-dissociate' into maintLibravatar Junio C Hamano1-1/+3
"git clone --dissociate" runs a big "git repack" process at the end, and it helps to close file descriptors that are open on the packs and their idx files before doing so on filesystems that cannot remove a file that is still open. * js/clone-dissociate: clone --dissociate: avoid locking pack files sha1_file.c: add a function to release all packs sha1_file: consolidate code to close a pack's file descriptor t5700: demonstrate a Windows file locking issue with `git clone --dissociate`
2015-11-03Merge branch 'tk/stripspace' into maintLibravatar Junio C Hamano7-102/+42
The internal stripspace() function has been moved to where it logically belongs to, i.e. strbuf API, and the command line parser of "git stripspace" has been updated to use the parse_options API. * tk/stripspace: stripspace: use parse-options for command-line parsing strbuf: make stripspace() part of strbuf
2015-11-03Merge branch 'jk/repository-extension' into maintLibravatar Junio C Hamano3-9/+17
Prepare for Git on-disk repository representation to undergo backward incompatible changes by introducing a new repository format version "1", with an extension mechanism. * jk/repository-extension: introduce "preciousObjects" repository extension introduce "extensions" form of core.repositoryformatversion
2015-11-01show-branch: use argv_array for default argumentsLibravatar René Scharfe1-16/+8
Use argv_array instead of open-coding it. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-29merge-file: clamp exit code to maximum 127Libravatar Jeff King1-0/+3
Git-merge-file is documented to return one of three exit codes: - zero means the merge was successful - a negative number means an error occurred - a positive number indicates the number of conflicts Unfortunately, this all gets stuffed into an 8-bit return code. Which means that if you have 256 conflicts, this wraps to zero, and the merge appears to succeed (and commits a blob full of conflict-marker cruft!). This patch clamps the return value to a maximum of 127, which we should be able to safely represent everywhere. This also leaves 128-255 for other values. Shells (and some parts of git) will typically represent signal death as 128 plus the signal number. And negative values are typically coerced to an 8-bit unsigned value (so "return -1" ends up as 255). Technically negative returns have the same problem (e.g., "-256" wraps back to 0), but this is not a problem in practice, as the only negative value we use is "-1". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26use pop_commit() for consuming the first entry of a struct commit_listLibravatar René Scharfe5-37/+14
Instead of open-coding the function pop_commit() just call it. This makes the intent clearer and reduces code size. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26Correct fscanf formatting string for I64u valuesLibravatar Waldek Maleska1-1/+1
This fix is probably purely cosmetic because PRIuMAX is likely identical to SCNuMAX. Nevertheless, when using a function of the scanf() family, the correct interpolation to use is the latter, not the former. Signed-off-by: Waldek Maleska <w.maleska@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26blame: fix option name in error messageLibravatar Max Kirillov1-1/+1
The option name used in blame's UI is `--reverse`. Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-24add: simplify -u/-A without pathspecLibravatar Junio C Hamano1-7/+1
Since Git 2.0, "add -u" and "add -A" run from a subdirectory without any pathspec mean "everything in the working tree" (before 2.0, they were limited to the current directory). The limiting to the current directory was implemented by inserting "." to the command line when the end user did not give us any pathspec. At 2.0, we updated the code to insert ":/" (instead of '.') to consider everything from the top-level, by using a pathspec magic "top". The call to parse_pathspec() using the command line arguments is, however, made with PATHSPEC_PREFER_FULL option since 5a76aff1 (add: convert to use parse_pathspec, 2013-07-14), which predates Git 2.0. In retrospect, there was no need to turn "adding . to limit to the directory" into "adding :/ to unlimit to everywhere" in Git 2.0; instead we could just have done "if there is no pathspec on the command line, just let it be". The parse_pathspec() then would give us a pathspec that matches everything and all is well. Incidentally such a simplification also fixes a corner case bug that stems from the fact that ":/" does not necessarily mean any magic. A user would say "git --literal-pathspecs add -u :/" from the command line when she has a directory ':' and wants to add everything in it (and she knows that her :/ will be taken as 'everything under the sun' magic pathspec unless she disables the magic with --literal-pathspecs). The internal use of ':/' would behave the same way as such an explicitly given ":/" when run with "--literal-pathspecs", and will not add everything under the sun as the code originally intended. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-18worktree: usage: denote <branch> as optional with 'add'Libravatar Sidhant Sharma1-1/+1
Although 1eb07d8 (worktree: add: auto-vivify new branch when <branch> is omitted, 2015-07-06) updated the documentation when <branch> became optional, it neglected to update the in-code usage message. Fix this oversight. Reported-by: ch3cooli@gmail.com Signed-off-by: Sidhant Sharma <tigerkid001@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16usage: do not insist that standard input must come from a fileLibravatar Junio C Hamano11-12/+12
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>
2015-10-16Merge branch 'nd/ls-remote-does-not-have-u-option' into maintLibravatar Junio C Hamano1-1/+1
* nd/ls-remote-does-not-have-u-option: ls-remote.txt: delete unsupported option
2015-10-16Merge branch 'jc/fsck-dropped-errors' into maintLibravatar Junio C Hamano1-4/+14
There were some classes of errors that "git fsck" diagnosed to its standard error that did not cause it to exit with non-zero status. * jc/fsck-dropped-errors: fsck: exit with non-zero when problems are found
2015-10-16Merge branch 'pt/am-builtin' into maintLibravatar Junio C Hamano1-1/+12
When "git am" was rewritten as a built-in, it stopped paying attention to user.signingkey, which was fixed. * pt/am-builtin: am: configure gpg at startup
2015-10-16Merge branch 'jk/blame-first-parent' into maintLibravatar Junio C Hamano1-1/+10
"git blame --first-parent v1.0..v2.0" was not rejected but did not limit the blame to commits on the first parent chain. * jk/blame-first-parent: blame: handle --first-parent
2015-10-16Merge branch 'pt/pull-builtin' into maintLibravatar Junio C Hamano1-1/+1
* pt/pull-builtin: pull: enclose <options> in brackets in the usage string merge: grammofix in please-commit-before-merge message
2015-10-16am, credential-cache: add angle brackets to usage stringLibravatar Ralf Thielow1-2/+2
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16stripspace: use parse-options for command-line parsingLibravatar Tobias Klauser1-26/+31
Use parse-options to parse command-line options instead of a hand-crafted implementation. The users can now use a unique prefix of the long option to say e.g. "git stripspace --strip". Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16strbuf: make stripspace() part of strbufLibravatar Tobias Klauser7-77/+12
This function is also used in other builtins than stripspace, so it makes sense to have it in a more generic place. Since it operates on an strbuf and the function is declared in strbuf.h, move it to strbuf.c and add the corresponding prefix to its name, just like other API functions in the strbuf_* family. Also switch all current users of stripspace() to the new function name and keep a temporary wrapper inline function for any topic branches still using stripspace(). Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16pull: enclose <options> in brackets in the usage stringLibravatar Alex Henrie1-1/+1
All the other placeholders are already shown that way. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-09am -3: do not let failed merge from completing the error codepathLibravatar Junio C Hamano1-16/+33
When "am" was rewritten in C, the codepath for falling back to three-way merge was mistakenly made to make an internal call to merge-recursive, disabling the error reporting code for certain types of errors merge-recursive detects and reports by calling die(). This is a quick-fix for correctness. The ideal endgame would be to replace run_command() in run_fallback_merge_recursive() with a direct call after making sure that internal call to merge-recursive does not die(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-07clone --dissociate: avoid locking pack filesLibravatar Johannes Schindelin1-1/+3
When `git clone` is asked to dissociate the repository from the reference repository whose objects were used, it is quite possible that the pack files need to be repacked. In that case, the pack files need to be deleted that were originally hard-links to the reference repository's pack files. On platforms where a file cannot be deleted if another process still holds a handle on it, we therefore need to take pains to release all pack files and indexes before dissociating. This fixes https://github.com/git-for-windows/git/issues/446 The test case to demonstrate the breakage technically does not need to be run on Linux or MacOSX. It won't hurt, either, though. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-30am: configure gpg at startupLibravatar Renee Margaret McConahy1-1/+12
The new builtin am ignores the user.signingkey variable: gpg is being called with the committer details as the key ID, which may not be correct. git_gpg_config is responsible for handling that variable and is expected to be called on initialization by any modules that use gpg. Signed-off-by: Renee Margaret McConahy <nepella@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Sync with v2.5.4Libravatar Junio C Hamano4-8/+17
2015-09-28Sync with 2.4.10Libravatar Junio C Hamano4-8/+17
2015-09-28Sync with 2.3.10Libravatar Junio C Hamano4-8/+17
2015-09-28merge-file: enforce MAX_XDIFF_SIZE on incoming filesLibravatar Jeff King1-1/+2
The previous commit enforces MAX_XDIFF_SIZE at the interfaces to xdiff: xdi_diff (which calls xdl_diff) and ll_xdl_merge (which calls xdl_merge). But we have another direct call to xdl_merge in merge-file.c. If it were written today, this probably would just use the ll_merge machinery. But it predates that code, and uses slightly different options to xdl_merge (e.g., ZEALOUS_ALNUM). We could try to abstract out an xdi_merge to match the existing xdi_diff, but even that is difficult. Rather than simply report error, we try to treat large files as binary, and that distinction would happen outside of xdi_merge. The simplest fix is to just replicate the MAX_XDIFF_SIZE check in merge-file.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>