summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2016-01-12builtin/grep: add grep.fallbackToNoIndex configLibravatar Thomas Gummerer1-3/+9
Currently when git grep is used outside of a git repository without the --no-index option git simply dies. For convenience, add a grep.fallbackToNoIndex configuration variable. If set to true, git grep behaves like git grep --no-index if it is run outside of a git repository. It defaults to false, preserving the current behavior. Helped-by: Jeff King <peff@peff.net> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
2015-09-28react to errors in xdi_diffLibravatar Jeff King3-7/+15
When we call into xdiff to perform a diff, we generally lose the return code completely. Typically by ignoring the return of our xdi_diff wrapper, but sometimes we even propagate that return value up and then ignore it later. This can lead to us silently producing incorrect diffs (e.g., "git log" might produce no output at all, not even a diff header, for a content-level diff). In practice this does not happen very often, because the typical reason for xdiff to report failure is that it malloc() failed (it uses straight malloc, and not our xmalloc wrapper). But it could also happen when xdiff triggers one our callbacks, which returns an error (e.g., outf() in builtin/rerere.c tries to report a write failure in this way). And the next patch also plans to add more failure modes. Let's notice an error return from xdiff and react appropriately. In most of the diff.c code, we can simply die(), which matches the surrounding code (e.g., that is what we do if we fail to load a file for diffing in the first place). This is not that elegant, but we are probably better off dying to let the user know there was a problem, rather than simply generating bogus output. We could also just die() directly in xdi_diff, but the callers typically have a bit more context, and can provide a better message (and if we do later decide to pass errors up, we're one step closer to doing so). There is one interesting case, which is in diff_grep(). Here if we cannot generate the diff, there is nothing to match, and we silently return "no hits". This is actually what the existing code does already, but we make it a little more explicit. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04Sync with 2.3.9Libravatar Junio C Hamano1-2/+4
2015-09-04Sync with 2.2.3Libravatar Junio C Hamano1-2/+4
2015-09-04show-branch: use a strbuf for reflog descriptionsLibravatar Jeff King1-2/+4
When we show "branch@{0}", we format into a fixed-size buffer using sprintf. This can overflow if you have long branch names. We can fix it by using a temporary strbuf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'ss/clone-guess-dir-name-simplify' into maintLibravatar Junio C Hamano1-13/+6
Code simplification. * ss/clone-guess-dir-name-simplify: clone: simplify string handling in guess_dir_name()
2015-08-03Merge branch 'mh/reporting-broken-refs-from-for-each-ref' into maintLibravatar Junio C Hamano1-0/+5
"git for-each-ref" reported "missing object" for 0{40} when it encounters a broken ref. The lack of object whose name is 0{40} is not the problem; the ref being broken is. * mh/reporting-broken-refs-from-for-each-ref: read_loose_refs(): treat NULL_SHA1 loose references as broken read_loose_refs(): simplify function logic for-each-ref: report broken references correctly t6301: new tests of for-each-ref error handling
2015-07-27Merge branch 'ls/hint-rev-list-count' into maintLibravatar Junio C Hamano1-0/+1
* ls/hint-rev-list-count: rev-list: add --count to usage guide
2015-07-27Merge branch 'jk/rev-list-no-bitmap-while-pruning' into maintLibravatar Junio C Hamano1-1/+1
A minor bugfix when pack bitmap is used with "rev-list --count". * jk/rev-list-no-bitmap-while-pruning: rev-list: disable --use-bitmap-index when pruning commits
2015-07-27Merge branch 'jk/index-pack-reduce-recheck' into maintLibravatar Junio C Hamano1-1/+1
Disable "have we lost a race with competing repack?" check while receiving a huge object transfer that runs index-pack. * jk/index-pack-reduce-recheck: index-pack: avoid excessive re-reading of pack directory
2015-07-15Merge branch 'mh/fsck-reflog-entries' into maintLibravatar Junio C Hamano1-14/+20
"git fsck" used to ignore missing or invalid objects recorded in reflog. * mh/fsck-reflog-entries: fsck: report errors if reflog entries point at invalid objects fsck_handle_reflog_sha1(): new function
2015-07-15Merge branch 'jc/do-not-feed-tags-to-clear-commit-marks' into maintLibravatar Junio C Hamano1-6/+6
"git format-patch --ignore-if-upstream A..B" did not like to be fed tags as boundary commits. * jc/do-not-feed-tags-to-clear-commit-marks: format-patch: do not feed tags to clear_commit_marks()
2015-07-09clone: simplify string handling in guess_dir_name()Libravatar Sebastian Schuberth1-13/+6
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-01rev-list: disable --use-bitmap-index when pruning commitsLibravatar Jeff King1-1/+1
The reachability bitmaps do not have enough information to tell us which commits might have changed path "foo", so the current code produces wrong answers for: git rev-list --use-bitmap-index --count HEAD -- foo (it silently ignores the "foo" limiter). Instead, we should fall back to doing a normal traversal (it is OK to fall back rather than complain, because --use-bitmap-index is a pure optimization, and might not kick in for other reasons, such as there being no bitmaps in the repository). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-01rev-list: add --count to usage guideLibravatar Lawrence Siebert1-0/+1
--count should be mentioned in the usage guide, this updates code and documentation. Signed-off-by: Lawrence Siebert <lawrencesiebert@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-16Merge branch 'jk/clone-dissociate' into maintLibravatar Junio C Hamano1-13/+4
Code clean-up. * jk/clone-dissociate: clone: reorder --dissociate and --reference options clone: use OPT_STRING_LIST for --reference
2015-06-16Merge branch 'ah/usage-strings' into maintLibravatar Junio C Hamano2-2/+2
A few usage string updates. * ah/usage-strings: blame, log: format usage strings similarly to those in documentation
2015-06-16Merge branch 'rs/janitorial' into maintLibravatar Junio C Hamano3-16/+4
Code clean-up. * rs/janitorial: dir: remove unused variable sb clean: remove unused variable buf use file_exists() to check if a file exists in the worktree
2015-06-16Merge branch 'dt/clean-pathspec-filter-then-lstat' into maintLibravatar Junio C Hamano1-3/+3
"git clean pathspec..." tried to lstat(2) and complain even for paths outside the given pathspec. * dt/clean-pathspec-filter-then-lstat: clean: only lstat files in pathspec
2015-06-09index-pack: avoid excessive re-reading of pack directoryLibravatar Jeff King1-1/+1
Since 45e8a74 (has_sha1_file: re-check pack directory before giving up, 2013-08-30), we spend extra effort for has_sha1_file to give the right answer when somebody else is repacking. Usually this effort does not matter, because after finding that the object does not exist, the next step is usually to die(). However, some code paths make a large number of has_sha1_file checks which are _not_ expected to return 1. The collision test in index-pack.c is such a case. On a local system, this can cause a performance slowdown of around 5%. But on a system with high-latency system calls (like NFS), it can be much worse. This patch introduces a "quick" flag to has_sha1_file which callers can use when they would prefer high performance at the cost of false negatives during repacks. There may be other code paths that can use this, but the index-pack one is the most obviously critical, so we'll start with switching that one. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-08fsck: report errors if reflog entries point at invalid objectsLibravatar Michael Haggerty1-4/+9
Previously, if a reflog entry's old or new SHA-1 was not resolvable to an object, that SHA-1 was silently ignored. Instead, report such cases as errors. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-08fsck_handle_reflog_sha1(): new functionLibravatar Michael Haggerty1-14/+15
New function, extracted from fsck_handle_reflog_ent(). The extra is_null_sha1() test for the new reference is currently unnecessary, as reflogs are deleted when the reference itself is deleted. But it doesn't hurt, either. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-05Merge branch 'dl/branch-error-message' into maintLibravatar Junio C Hamano1-3/+3
Error messages from "git branch" called remote-tracking branches as "remote branches". * dl/branch-error-message: branch: do not call a "remote-tracking branch" a "remote branch"
2015-06-05Merge branch 'ps/bundle-verify-arg' into maintLibravatar Junio C Hamano1-0/+8
"git bundle verify" did not diagnose extra parameters on the command line. * ps/bundle-verify-arg: bundle: verify arguments more strictly
2015-06-05Merge branch 'jk/add-e-kill-editor' into maintLibravatar Junio C Hamano1-1/+2
"git add -e" did not allow the user to abort the operation by killing the editor. * jk/add-e-kill-editor: add: check return value of launch_editor
2015-06-05Merge branch 'mh/clone-verbosity-fix' into maintLibravatar Junio C Hamano1-2/+2
Git 2.4 broke setting verbosity and progress levels on "git clone" with native transports. * mh/clone-verbosity-fix: clone: call transport_set_verbosity before anything else on the newly created transport
2015-06-05Merge branch 'jk/sha1-file-reduce-useless-warnings' into maintLibravatar Junio C Hamano1-3/+1
* jk/sha1-file-reduce-useless-warnings: sha1_file: squelch "packfile cannot be accessed" warnings
2015-06-05Merge branch 'tb/blame-resurrect-convert-to-git' into maintLibravatar Junio C Hamano1-0/+1
Some time ago, "git blame" (incorrectly) lost the convert_to_git() call when synthesizing a fake "tip" commit that represents the state in the working tree, which broke folks who record the history with LF line ending to make their project portabile across platforms while terminating lines in their working tree files with CRLF for their platform. * tb/blame-resurrect-convert-to-git: blame: CRLF in the working tree and LF in the repo
2015-06-05Merge branch 'jc/plug-fmt-merge-msg-leak' into maintLibravatar Junio C Hamano1-5/+11
* jc/plug-fmt-merge-msg-leak: fmt-merge-msg: plug small leak of commit buffer
2015-06-05Merge branch 'pt/xdg-config-path' into maintLibravatar Junio C Hamano2-9/+5
Code clean-up for xdg configuration path support. * pt/xdg-config-path: path.c: remove home_config_paths() git-config: replace use of home_config_paths() git-commit: replace use of home_config_paths() credential-store.c: replace home_config_paths() with xdg_config_home() dir.c: replace home_config_paths() with xdg_config_home() attr.c: replace home_config_paths() with xdg_config_home() path.c: implement xdg_config_home() t0302: "unreadable" test needs POSIXPERM t0302: test credential-store support for XDG_CONFIG_HOME git-credential-store: support XDG_CONFIG_HOME git-credential-store: support multiple credential files
2015-06-02for-each-ref: report broken references correctlyLibravatar Michael Haggerty1-0/+5
If there is a loose reference file with invalid contents, "git for-each-ref" incorrectly reports the problem as being a missing object with name NULL_SHA1: $ echo '12345678' >.git/refs/heads/nonsense $ git for-each-ref fatal: missing object 0000000000000000000000000000000000000000 for refs/heads/nonsense With an explicit "--format" string, it can even report that the reference validly points at NULL_SHA1: $ git for-each-ref --format='%(objectname) %(refname)' 0000000000000000000000000000000000000000 refs/heads/nonsense $ echo $? 0 This has been broken since b7dd2d2 for-each-ref: Do not lookup objects when they will not be used (2009-05-27) , which changed for-each-ref from using for_each_ref() to using git_for_each_rawref() in order to avoid looking up the referred-to objects unnecessarily. (When "git for-each-ref" is given a "--format" string that doesn't include information about the pointed-to object, it does not look up the object at all, which makes it considerably faster. Iterating with DO_FOR_EACH_INCLUDE_BROKEN is essential to this optimization because otherwise for_each_ref() would itself need to check whether the object exists as part of its brokenness test.) But for_each_rawref() includes broken references in the iteration, and "git for-each-ref" doesn't itself reject references with REF_ISBROKEN. The result is that broken references are processed *as if* they had the value NULL_SHA1, which is the value stored in entries for broken references. Change "git for-each-ref" to emit warnings for references that are REF_ISBROKEN but to otherwise skip them. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01format-patch: do not feed tags to clear_commit_marks()Libravatar Junio C Hamano1-6/+6
"git format-patch --ignore-if-in-upstream A..B", when either A or B is a tag, failed miserably. This is because the code passes the tips it used for traversal to clear_commit_marks(), after running a temporary revision traversal to enumerate the commits on both branches to find if they have commits that make equivalent changes. The revision traversal machinery knows how to enumerate commits reachable starting from a tag, but clear_commit_marks() wants to take nothing but a commit. In the longer term, it might be a more correct fix to teach clear_commit_marks() to do the same "committish to commit" dereferencing that is done in the revision traversal machinery, but for now this fix should suffice. Reported-by: Bruce Korb <bruce.korb@gmail.com> Helped-by: Christian Couder <christian.couder@gmail.com> Helped-by: brian m. carlson <sandals@crustytoothpaste.net> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-27clone: reorder --dissociate and --reference optionsLibravatar Jeff King1-2/+2
These options are intimately related, so it makes sense to list them nearby in the "-h" output (they are already adjacent in the manpage). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-27clone: use OPT_STRING_LIST for --referenceLibravatar Jeff King1-11/+2
Not only does this save us having to implement a custom callback, but it handles "--no-reference" in the usual way (to clear the list). The generic callback does copy the string, which we don't technically need, but that should not hurt anything. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-26Merge branch 'jc/hash-object' into maintLibravatar Junio C Hamano1-3/+1
"hash-object --literally" introduced in v2.2 was not prepared to take a really long object type name. * jc/hash-object: write_sha1_file(): do not use a separate sha1[] array t1007: add hash-object --literally tests hash-object --literally: fix buffer overrun with extra-long object type git-hash-object.txt: document --literally option
2015-05-20clean: remove unused variable bufLibravatar René Scharfe1-2/+0
It had never been used. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-20use file_exists() to check if a file exists in the worktreeLibravatar René Scharfe2-14/+4
Call file_exists() instead of open-coding it. That's shorter, simpler and the intent becomes clearer. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-19clone: call transport_set_verbosity before anything else on the newly ↵Libravatar Mike Hommey1-2/+2
created transport Commit 2879bc3 made the progress and verbosity options sent to remote helper earlier than they previously were. But nothing else after that would send updates if the value is changed later on with transport_set_verbosity. While for fetch and push, transport_set_verbosity is the first thing that is done after creating the transport, it was not the case for clone. So commit 2879bc3 broke changing progress and verbosity for clone, for urls requiring a remote helper only (so, not git:// urls, for instance). Moving transport_set_verbosity to just after the transport is created works around the issue. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-18clean: only lstat files in pathspecLibravatar David Turner1-3/+3
Even though "git clean" takes pathspec to limit the part of the working tree to be cleaned, it checked the paths it encounters during its directory traversal with lstat(2), before checking if the path is within the pathspec. Ignore paths outside pathspec and proceed without checking with lstat(2). Even if such a path is unreadable due to e.g. EPERM, "git clean" should not care. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-13Merge branch 'jk/init-core-worktree-at-root' into maintLibravatar Junio C Hamano1-3/+15
We avoid setting core.worktree when the repository location is the ".git" directory directly at the top level of the working tree, but the code misdetected the case in which the working tree is at the root level of the filesystem (which arguably is a silly thing to do, but still valid). * jk/init-core-worktree-at-root: init: don't set core.worktree when initializing /.git
2015-05-12add: check return value of launch_editorLibravatar Jeff King1-1/+2
When running "add -e", if launching the editor fails, we do not notice and continue as if the output is what the user asked for. The likely case is that the editor did not touch the contents at all, and we end up adding everything. Reported-by: Russ Cox <rsc@golang.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-11Sync with 2.3.8Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-11Merge branch 'oh/fix-config-default-user-name-section' into maint-2.3Libravatar Junio C Hamano1-2/+2
The default $HOME/.gitconfig file created upon "git config --global" that edits it had incorrectly spelled user.name and user.email entries in it. * oh/fix-config-default-user-name-section: config: fix settings in default_user_config template
2015-05-08bundle: verify arguments more strictlyLibravatar Patrick Steinhardt1-0/+8
The `verify` and `create` subcommands of the bundle builtin do not properly verify the command line arguments that have been passed in. While the `verify` subcommand accepts an arbitrary amount of ignored arguments the `create` subcommand does not complain about being passed too few arguments, resulting in a bogus call to `git rev-list`. Fix these errors by verifying that the correct amount of arguments has been passed in. Signed-off-by: Patrick Steinhardt <ps@pks.im> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-06branch: do not call a "remote-tracking branch" a "remote branch"Libravatar Danny Lin1-3/+3
"git branch -r -d" mentions "delete remote branch", which should be "remote-tracking branch". Signed-off-by: Danny Lin <danny0838@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-06git-config: replace use of home_config_paths()Libravatar Paul Tan1-4/+2
Since home_config_paths() combines distinct functionality already implemented by expand_user_path() and xdg_config_home(), and hides the home config file path ~/.gitconfig. Make the code more explicit by replacing the use of home_config_paths() with expand_user_path() and xdg_config_home(). Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-06git-commit: replace use of home_config_paths()Libravatar Paul Tan1-5/+3
Since home_config_paths() combines two distinct functionality already implemented by expand_user_path() and xdg_config_home(), and hides the home config file path ~/.gitconfig. Make the code more explicit by replacing the use of home_config_paths() with expand_user_path() and xdg_config_home(). Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-05hash-object --literally: fix buffer overrun with extra-long object typeLibravatar Eric Sunshine1-3/+1
"hash-object" learned in 5ba9a93 (hash-object: add --literally option, 2014-09-11) to allow crafting a corrupt/broken object of unknown type. When the user-provided type is particularly long, however, it can overflow the relatively small stack-based character array handed to write_sha1_file_prepare() by hash_sha1_file() and write_sha1_file(), leading to stack corruption (and crash). Introduce a custom helper to allow arbitrarily long typenames just for "hash-object --literally". [jc: Eric's original used a strbuf in the more common codepaths, and I rewrote it to avoid penalizing the non-literally code. Bugs are mine] Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>