summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
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-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-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-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>
2015-05-03blame, log: format usage strings similarly to those in documentationLibravatar Alex Henrie2-2/+2
Earlier, 9c9b4f2f (standardize usage info string format, 2015-01-13) tried to make usage-string in line with the documentation by - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing <foobar>* with [<foobar>...] but it missed a few places. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-03blame: CRLF in the working tree and LF in the repoLibravatar Torsten Bögershausen1-0/+1
A typical setup under Windows is to set core.eol to CRLF, and text files are marked as "text" in .gitattributes, or core.autocrlf is set to true. After 4d4813a5 "git blame" no longer works as expected for such a set-up. Every line is annotated as "Not Committed Yet", even though the working directory is clean. This is because the commit removed the conversion in blame.c for all files, with or without CRLF in the repo. Having files with CRLF in the repo and core.autocrlf=input is a temporary situation, and the files, if committed as is, will be normalized in the repo, which _will_ be a notable change. Blaming them with "Not Committed Yet" is the right result. Revert commit 4d4813a5 which was a misguided attempt to "solve" a non-problem. Add two test cases in t8003 to verify the correct CRLF conversion. Suggested-By: Stepan Kasal <kasal@ucw.cz> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-20Merge branch 'ps/grep-help-all-callback-arg'Libravatar Junio C Hamano1-1/+1
Code clean-up. * ps/grep-help-all-callback-arg: grep: correctly initialize help-all option
2015-04-20fmt-merge-msg: plug small leak of commit bufferLibravatar Junio C Hamano1-5/+11
A broken or badly formatted commit might not record author or committer lines or we may not find a valid name on them. The function record_person() returned after calling get_commit_buffer() without calling unuse_commit_buffer() on the memory it obtained in such cases, potentially leaking it. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-17config: fix settings in default_user_config templateLibravatar Ossi Herrala1-2/+2
The name (not user) and email setting should be in config section "user" and not in "core" as documented in Documentation/config.txt. Signed-off-by: Ossi Herrala <oherrala@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-16Revert "merge: pass verbosity flag down to merge-recursive"Libravatar Junio C Hamano1-4/+0
This reverts commit 2bf15a3330a26183adc8563dbeeacc11294b8a01, whose intention was good, but the verbosity levels used in merge-recursive turns out to be rather uneven. For example, a merge of two branches with conflicting submodule updates used to report CONFLICT: output with --quiet but no longer (which *is* desired), while the final "Automatic merge failed; fix conflicts and then commit" message is still shown even with --quiet (which *is* inconsistent). Originally reported by Bryan Turner; it is too early to declare what the concensus is, but it seems that we would need to level the verbosity levels used in merge strategy backends before we can go forward. In the meantime, we'd revert to the old behaviour until that happens. cf. $gmane/267245
2015-04-14Merge branch 'jk/merge-quiet'Libravatar Junio C Hamano1-0/+4
"git merge --quiet" did not squelch messages from the underlying merge-recursive strategy. * jk/merge-quiet: merge: pass verbosity flag down to merge-recursive
2015-04-14Merge branch 'jc/update-instead-into-void'Libravatar Junio C Hamano1-1/+20
A push into an unborn branch, with "receive.denyCurrentBranch" set to "updateInstead", did not check out the working tree as expected. * jc/update-instead-into-void: push-to-deploy: allow pushing into an unborn branch and updating it
2015-04-12grep: correctly initialize help-all optionLibravatar Patrick Steinhardt1-1/+1
The "help-all" option is being initialized with a wrong value. While being semantically wrong this can also cause a segmentation fault in gcc on ARMv7 hardfloat platforms with a hardened toolchain. Fix this by initializing with a NULL value. Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-02merge: pass verbosity flag down to merge-recursiveLibravatar Jeff King1-0/+4
This makes "git merge --quiet" really quiet when we call into merge-recursive. Note that we can't just pass our flag down as-is; the two parts of the code use different scales. We center at "0" as normal for git-merge (with "--quiet" giving a negative value), but merge-recursive uses "2" as its center. This patch passes a negative value to merge-recursive rather than "1", though, as otherwise the user would have to use "-qqq" to squelch all messages (but the downside is that the user cannot distinguish between levels 0-2 if without resorting to the GIT_MERGE_VERBOSITY variable). We may want to review and renormalize the message severities in merge-recursive, but that does not have to happen now. This is at least in improvement in the sense that we are respecting "--quiet" at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-02init: don't set core.worktree when initializing /.gitLibravatar Jeff King1-3/+15
If you create a git repository in the root directory with "git init /", we erroneously write a core.worktree entry. This isn't _wrong_, in the sense that it's OK to set core.worktree when we don't need to. But it is unnecessarily surprising if you later move the .git directory to another path (which usually moves the relative working tree, but is foiled if there is an explicit worktree set). The problem is that we check whether core.worktree is necessary by seeing if we can make the git_dir by concatenating "/.git" onto the working tree. That would lead to "//.git" in this instance, but we actually have "/.git" (without the doubled slash). We can fix this by special-casing the root directory. I also split the logic out into its own function to make the conditional a bit more readable (and used skip_prefix, which I think makes it a little more obvious what is going on). No tests, as we would need to be able to write to "/" to do so. I did manually confirm that: sudo git init / cd / git rev-parse --show-toplevel git config core.worktree still finds the top-level correctly (as "/"), and does not set any core.worktree variable. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-01push-to-deploy: allow pushing into an unborn branch and updating itLibravatar Junio C Hamano1-1/+20
Setting receive.denycurrentbranch to updateinstead and pushing into the current branch, when the working tree and the index is truly clean, is supposed to reset the working tree and the index to match the tree of the pushed commit. This did not work when pushing into an unborn branch. The code that drives push-to-checkout hook needs no change, as the interface is defined so that hook can decide what to do when the push is coming to an unborn branch and take an appropriate action since the beginning. Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-31Merge branch 'jc/report-path-error-to-dir' into maintLibravatar Junio C Hamano1-43/+0
Code clean-up. * jc/report-path-error-to-dir: report_path_error(): move to dir.c
2015-03-30sha1_file: squelch "packfile cannot be accessed" warningsLibravatar Jeff King1-3/+1
When we find an object in a packfile index, we make sure we can still open the packfile itself (or that it is already open), as it might have been deleted by a simultaneous repack. If we can't access the packfile, we print a warning for the user and tell the caller that we don't have the object (we can then look in other packfiles, or find a loose version, before giving up). The warning we print to the user isn't really accomplishing anything, and it is potentially confusing to users. In the normal case, it is complete noise; we find the object elsewhere, and the user does not have to care that we racily saw a packfile index that became stale. It didn't affect the operation at all. A possibly more interesting case is when we later can't find the object, and report failure to the user. In this case the warning could be considered a clue toward that ultimate failure. But it's not really a useful clue in practice. We wouldn't even print it consistently (since we are racing with another process, we might not even see the .idx file, or we might win the race and open the packfile, completing the operation). This patch drops the warning entirely (not only from the fill_pack_entry site, but also from an identical use in pack-objects). If we did find the warning interesting in the error case, we could stuff it away and reveal it to the user when we later die() due to the broken object. But that complexity just isn't worth it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-28Merge branch 'ws/grep-quiet-no-pager' into maintLibravatar Junio C Hamano1-1/+1
Even though "git grep --quiet" is run merely to ask for the exit status, we spawned the pager regardless. Stop doing that. * ws/grep-quiet-no-pager: grep: fix "--quiet" overwriting current output
2015-03-28Merge branch 'jk/cleanup-failed-clone' into maintLibravatar Junio C Hamano1-5/+6
An failure early in the "git clone" that started creating the working tree and repository could have resulted in some directories and files left without getting cleaned up. * jk/cleanup-failed-clone: clone: drop period from end of die_errno message clone: initialize atexit cleanup handler earlier
2015-03-28Merge branch 'jk/prune-with-corrupt-refs' into maintLibravatar Junio C Hamano2-2/+7
"git prune" used to largely ignore broken refs when deciding which objects are still being used, which could spread an existing small damage and make it a larger one. * jk/prune-with-corrupt-refs: refs.c: drop curate_packed_refs repack: turn on "ref paranoia" when doing a destructive repack prune: turn on ref_paranoia flag refs: introduce a "ref paranoia" flag t5312: test object deletion code paths in a corrupted repository