summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-02-05Merge branch 'pw/completion-stash' into maintLibravatar Junio C Hamano1-3/+14
* pw/completion-stash: completion: update completion arguments for stash
2016-02-05Merge branch 'pw/completion-show-branch' into maintLibravatar Junio C Hamano1-1/+1
* pw/completion-show-branch: completion: complete show-branch "--date-order"
2016-02-05Merge branch 'jk/completion-rebase' into maintLibravatar Junio C Hamano1-2/+6
* jk/completion-rebase: completion: add missing git-rebase options
2016-02-05Merge branch 'nd/diff-with-path-params' into maintLibravatar Junio C Hamano7-12/+25
A few options of "git diff" did not work well when the command was run from a subdirectory. * nd/diff-with-path-params: diff: make -O and --output work in subdirectory diff-no-index: do not take a redundant prefix argument
2016-02-05Merge branch 'dw/subtree-split-do-not-drop-merge' into maintLibravatar Junio C Hamano2-2/+70
The "split" subcommand of "git subtree" (in contrib/) incorrectly skipped merges when it shouldn't, which was corrected. * dw/subtree-split-do-not-drop-merge: contrib/subtree: fix "subtree split" skipped-merge bug
2016-02-05Merge branch 'ew/svn-1.9.0-auth' into maintLibravatar Junio C Hamano1-2/+6
* ew/svn-1.9.0-auth: git-svn: fix auth parameter handling on SVN 1.9.0+
2016-02-05Merge branch 'jk/list-tag-2.7-regression' into maintLibravatar Junio C Hamano7-56/+72
"git tag" started listing a tag "foo" as "tags/foo" when a branch named "foo" exists in the same repository; remove this unnecessary disambiguation, which is a regression introduced in v2.7.0. * jk/list-tag-2.7-regression: tag: do not show ambiguous tag names as "tags/foo" t6300: use test_atom for some un-modern tests
2016-02-05Merge branch 'jk/sanity' into maintLibravatar Junio C Hamano1-5/+13
The description for SANITY prerequisite the test suite uses has been clarified both in the comment and in the implementation. * jk/sanity: test-lib: clarify and tighten SANITY
2016-02-05Merge branch 'jk/filter-branch-no-index' into maintLibravatar Junio C Hamano2-1/+9
A recent optimization to filter-branch in v2.7.0 introduced a regression when --prune-empty filter is used, which has been corrected. * jk/filter-branch-no-index: filter-branch: resolve $commit^{tree} in no-index case
2016-02-05Merge branch 'js/close-packs-before-gc' into maintLibravatar Junio C Hamano5-0/+18
Many codepaths that run "gc --auto" before exiting kept packfiles mapped and left the file descriptors to them open, which was not friendly to systems that cannot remove files that are open. They now close the packs before doing so. * js/close-packs-before-gc: receive-pack: release pack files before garbage-collecting merge: release pack files before garbage-collecting am: release pack files before garbage-collecting fetch: release pack files before garbage-collecting
2016-02-05Merge branch 'jk/ok-to-fail-gc-auto-in-rebase' into maintLibravatar Junio C Hamano1-1/+1
"git rebase", unlike all other callers of "gc --auto", did not ignore the exit code from "gc --auto". * jk/ok-to-fail-gc-auto-in-rebase: rebase: ignore failures from "gc --auto"
2016-02-05Merge branch 'ho/gitweb-squelch-undef-warning' into maintLibravatar Junio C Hamano1-1/+1
Asking gitweb for a nonexistent commit left a warning in the server log. Somebody may want to follow this up with a new test, perhaps? IIRC, we do test that no Perl warnings are given to the server log, so this should have been caught if our test coverage were good. * ho/gitweb-squelch-undef-warning: gitweb: squelch "uninitialized value" warning
2016-02-05Merge branch 'js/fopen-harder' into maintLibravatar Junio C Hamano5-3/+17
Some codepaths used fopen(3) when opening a fixed path in $GIT_DIR (e.g. COMMIT_EDITMSG) that is meant to be left after the command is done. This however did not work well if the repository is set to be shared with core.sharedRepository and the umask of the previous user is tighter. They have been made to work better by calling unlink(2) and retrying after fopen(3) fails with EPERM. * js/fopen-harder: Handle more file writes correctly in shared repos commit: allow editing the commit message even in shared repos
2016-02-05Merge branch 'nd/exclusion-regression-fix' into maintLibravatar Junio C Hamano3-118/+6
The ignore mechanism saw a few regressions around untracked file listing and sparse checkout selection areas in 2.7.0; the change that is responsible for the regression has been reverted. * nd/exclusion-regression-fix: Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"
2016-02-05Merge branch 'dk/reflog-walk-with-non-commit' into maintLibravatar Junio C Hamano2-5/+24
"git reflog" incorrectly assumed that all objects that used to be at the tip of a ref must be commits, which caused it to segfault. * dk/reflog-walk-with-non-commit: reflog-walk: don't segfault on non-commit sha1's in the reflog
2016-02-05Merge branch 'dw/signoff-doc' into maintLibravatar Junio C Hamano5-1/+9
The documentation has been updated to hint the connection between the '--signoff' option and DCO. * dw/signoff-doc: Expand documentation describing --signoff
2016-02-05Merge branch 'jk/clang-pedantic' into maintLibravatar Junio C Hamano4-5/+6
A few unportable C construct have been spotted by clang compiler and have been fixed. * jk/clang-pedantic: bswap: add NO_UNALIGNED_LOADS define avoid shifting signed integers 31 bits
2016-02-05Merge branch 'ew/send-email-mutt-alias-fix' into maintLibravatar Junio C Hamano2-2/+22
"git send-email" was confused by escaped quotes stored in the alias files saved by "mutt", which has been corrected. * ew/send-email-mutt-alias-fix: git-send-email: do not double-escape quotes from mutt
2016-02-05Merge branch 'nd/dir-exclude-cleanup' into maintLibravatar Junio C Hamano1-3/+1
The "exclude_list" structure has the usual "alloc, nr" pair of fields to be used by ALLOC_GROW(), but clear_exclude_list() forgot to reset 'alloc' to 0 when it cleared 'nr' to discard the managed array. * nd/dir-exclude-cleanup: dir.c: clean the entire struct in clear_exclude_list()
2016-02-05Merge branch 'nd/stop-setenv-work-tree' into maintLibravatar Junio C Hamano2-3/+1
An earlier change in 2.5.x-era broke users' hooks and aliases by exporting GIT_WORK_TREE to point at the root of the working tree, interfering when they tried to use a different working tree without setting GIT_WORK_TREE environment themselves. * nd/stop-setenv-work-tree: Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"
2016-01-26git-svn: fix auth parameter handling on SVN 1.9.0+Libravatar Eric Wong1-2/+6
For users with "store-passwords = no" set in the "[auth]" section of their ~/.subversion/config, SVN 1.9.0+ would fail with the following message when attempting to call svn_auth_set_parameter: Value is not a string (or undef) at Git/SVN/Ra.pm Ironically, this breakage was caused by r1553823 in subversion: "Make svn_auth_set_parameter() usable from Perl bindings." Since 2007 (602015e0e6ec), git-svn has used a workaround to make svn_auth_set_parameter usable internally. However this workaround breaks under SVN 1.9+, which deals properly with the type mapping and fails to recognize our workaround. For pre-1.9.0 SVN, we continue to use the existing workaround for the lack of proper type mapping in the bindings. Tested under subversion 1.6.17 and 1.9.3. I've also verified r1553823 was not backported to SVN 1.8.x: BRANCH=http://svn.apache.org/repos/asf/subversion/branches/1.8.x svn log -v $BRANCH/subversion/bindings/swig/core.i ref: https://bugs.debian.org/797705 Cc: 797705@bugs.debian.org Reported-by: Thierry Vignaud <thierry.vignaud@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Tested-by: Thierry Vignaud <thierry.vignaud@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26tag: do not show ambiguous tag names as "tags/foo"Libravatar Jeff King7-4/+62
Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11), git-tag has started showing tags with ambiguous names (i.e., when both "heads/foo" and "tags/foo" exists) as "tags/foo" instead of just "foo". This is both: - pointless; the output of "git tag" includes only refs/tags, so we know that "foo" means the one in "refs/tags". and - ambiguous; in the original output, we know that the line "foo" means that "refs/tags/foo" exists. In the new output, it is unclear whether we mean "refs/tags/foo" or "refs/tags/tags/foo". The reason this happens is that commit b7cc53e9 switched git-tag to use ref-filter's "%(refname:short)" output formatting, which was adapted from for-each-ref. This more general code does not know that we care only about tags, and uses shorten_unambiguous_ref to get the short-name. We need to tell it that we care only about "refs/tags/", and it should shorten with respect to that value. In theory, the ref-filter code could figure this out by us passing FILTER_REFS_TAGS. But there are two complications there: 1. The handling of refname:short is deep in formatting code that does not even have our ref_filter struct, let alone the arguments to the filter_ref struct. 2. In git v2.7.0, we expose the formatting language to the user. If we follow this path, it will mean that "%(refname:short)" behaves differently for "tag" versus "for-each-ref" (including "for-each-ref refs/tags/"), which can lead to confusion. Instead, let's add a new modifier to the formatting language, "strip", to remove a specific set of prefix components. This fixes "git tag", and lets users invoke the same behavior from their own custom formats (for "tag" or "for-each-ref") while leaving ":short" with its same consistent meaning in all places. We introduce a test in t7004 for "git tag", which fails without this patch. We also add a similar test in t3203 for "git branch", which does not actually fail. But since it is likely that "branch" will eventually use the same formatting code, the test helps defend against future regressions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26completion: update completion arguments for stashLibravatar Paul Wagland1-3/+14
Add --all and --include-untracked to the git stash save completions. Add --quiet to the git stash drop completions. Update git stash branch so that the first argument expands out to the possible branch names, and the other arguments expand to the stash names. Signed-off-by: Paul Wagland <paul@kungfoocoder.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25completion: complete show-branch "--date-order"Libravatar Paul Wagland1-1/+1
Signed-off-by: Paul Wagland <paul@kungfoocoder.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25completion: add missing git-rebase optionsLibravatar John Keeping1-2/+6
This adds the --no-* variants where those are documented in git-rebase(1). Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25t6300: use test_atom for some un-modern testsLibravatar Jeff King1-52/+10
Because this script has to test so many formatters, we have the nice "test_atom" helper, but we don't use it consistently. Let's do so. This is shorter, gets rid of some tests that have their "expected" setup outside of a test_expect_success block, and lets us organize the changes better (e.g., putting "refname:short" near "refname"). We also expand the "%(push)" tests a little to match the "%(upstream)" ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-21diff: make -O and --output work in subdirectoryLibravatar Duy Nguyen6-8/+21
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-21diff-no-index: do not take a redundant prefix argumentLibravatar Nguyễn Thái Ngọc Duy3-4/+4
Prefix is already set up in "revs". The same prefix should be used for all options parsing. So kill the last argument. This patch does not actually change anything because the only caller does use the same prefix for init_revisions() and diff_no_index(). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-20contrib/subtree: fix "subtree split" skipped-merge bugLibravatar Dave Ware2-2/+70
'git subtree split' can incorrectly skip a merge even when both parents act on the subtree, provided the merge results in a tree identical to one of the parents. Fix by copying the merge if at least one parent is non-identical, and the non-identical parent is not an ancestor of the identical parent. Also, add a test case which checks that a descendant remains a descendent on the subtree in this case. Signed-off-by: Dave Ware <davidw@realtimegenomics.com> Reviewed-by: David A. Greene <greened@obbligato.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19filter-branch: resolve $commit^{tree} in no-index caseLibravatar Jeff King2-1/+9
Commit 348d4f2 (filter-branch: skip index read/write when possible, 2015-11-06) taught filter-branch to optimize out the final "git write-tree" when we know we haven't touched the tree with any of our filters. It does by simply putting the literal text "$commit^{tree}" into the "$tree" variable, avoiding a useless rev-parse call. However, when we pass this to git_commit_non_empty_tree(), it gets confused; it resolves "$commit^{tree}" itself, and compares our string to the 40-hex sha1, which obviously doesn't match. As a result, "--prune-empty" (or any custom filter using git_commit_non_empty_tree) will fail to drop an empty commit (when filter-branch is used without a tree or index filter). Let's resolve $tree to the 40-hex ourselves, so that git_commit_non_empty_tree can work. Unfortunately, this is a bit slower due to the extra process overhead: $ cd t/perf && ./run 348d4f2 HEAD p7000-filter-branch.sh [...] Test 348d4f2 HEAD -------------------------------------------------------------- 7000.2: noop filter 3.76(0.24+0.26) 4.54(0.28+0.24) +20.7% We could try to make git_commit_non_empty_tree more clever. However, the value of $tree here is technically user-visible. The user can provide arbitrary shell code at this stage, which could itself have a similar assumption to what is in git_commit_non_empty_tree. So the conservative choice to fix this regression is to take the 20% hit and give the pre-348d4f2 behavior. We still end up much faster than before the optimization: $ cd t/perf && ./run 348d4f2^ HEAD p7000-filter-branch.sh [...] Test 348d4f2^ HEAD -------------------------------------------------------------- 7000.2: noop filter 9.51(4.32+0.40) 4.51(0.28+0.23) -52.6% Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19test-lib: clarify and tighten SANITYLibravatar Junio C Hamano1-5/+13
f400e51c (test-lib.sh: set prerequisite SANITY by testing what we really need, 2015-01-27) improved the way SANITY prerequisite was determined, but made the resulting code (incorrectly) imply that SANITY is all about effects of permission bits of the containing directory has on the files contained in it by the comment it added, its log message and the actual tests. State what SANITY is about more clearly in the comment, and test that a file whose permission bits says should be unreadble truly cannot be read. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13rebase: ignore failures from "gc --auto"Libravatar Jeff King1-1/+1
After rebasing, we call "gc --auto" to clean up if we created a lot of loose objects. However, we do so inside an &&-chain. If "gc --auto" fails (e.g., because a previous background gc blocked us by leaving "gc.log" in place), then: 1. We will fail to clean up the state directory, leaving the user stuck in the rebase forever (even "git am --abort" doesn't work, because it calls "gc --auto"!). 2. In some cases, we may return a bogus exit code from rebase, indicating failure when everything except the auto-gc succeeded. We can fix this by ignoring the exit code of "gc --auto". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13receive-pack: release pack files before garbage-collectingLibravatar Johannes Schindelin1-0/+1
Before auto-gc'ing, we need to make sure that the pack files are released in case they need to be repacked and garbage-collected. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13merge: release pack files before garbage-collectingLibravatar Johannes Schindelin1-0/+1
Before auto-gc'ing, we need to make sure that the pack files are released in case they need to be repacked and garbage-collected. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13am: release pack files before garbage-collectingLibravatar Johannes Schindelin1-0/+1
Before auto-gc'ing, we need to make sure that the pack files are released in case they need to be repacked and garbage-collected. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13fetch: release pack files before garbage-collectingLibravatar Johannes Schindelin2-0/+15
Before auto-gc'ing, we need to make sure that the pack files are released in case they need to be repacked and garbage-collected. This fixes https://github.com/git-for-windows/git/issues/500 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12Merge branch 'maint' of git://github.com/git-l10n/git-po into maintLibravatar Junio C Hamano2-0/+11863
* 'maint' of git://github.com/git-l10n/git-po: l10n: ko.po: Add Korean translation
2016-01-12gitweb: squelch "uninitialized value" warningLibravatar Øyvind A. Holm1-1/+1
git_object() chomps $type that is read from "cat-file -t", but it does so before checking if $type is defined, resulting in a Perl warning in the server error log: gitweb.cgi: Use of uninitialized value $type in scalar chomp at [...]/gitweb.cgi line 7579., referer: [...] when trying to access a non-existing commit, for example: http://HOST/?p=PROJECT.git;a=commit;h=NON_EXISTING_COMMIT Check the value in $type before chomping. This will cause us to call href with its action parameter set to undef when formulating the URL to redirect to, but that is harmless, as the function treats a parameter that set to undef as if it does not exist. Signed-off-by: Øyvind A. Holm <sunny@sunbase.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-11Handle more file writes correctly in shared reposLibravatar Johannes Schindelin2-2/+2
In shared repositories, we have to be careful when writing files whose permissions do not allow users other than the owner to write them. In particular, we force the marks file of fast-export and the FETCH_HEAD when fetching to be rewritten from scratch. This commit does not touch other calls to fopen() that want to write files: - commands that write to working tree files (core.sharedRepository does not affect permission bits of working tree files), e.g. .rej file created by "apply --reject", result of applying a previous conflict resolution by "rerere", "git merge-file". - git am, when splitting mails (git-am correctly cleans up its directory after finishing, so there is no need to share those files between users) - git submodule clone, when writing the .git file, because the file will not be overwritten - git_terminal_prompt() in compat/terminal.c, because it is not writing to a file at all - git diff --output, because the output file is clearly not intended to be shared between the users of the current repository - git fast-import, when writing a crash report, because the reports' file names are unique due to an embedded process ID - mailinfo() in mailinfo.c, because the output is clearly not intended to be shared between the users of the current repository - check_or_regenerate_marks() in remote-testsvn.c, because this is only used for Git's internal testing - git fsck, when writing lost&found blobs (this should probably be changed, but left as a low-hanging fruit for future contributors). Note that this patch does not touch callers of write_file() and write_file_gently(), which would benefit from the same scrutiny as to usage in shared repositories. Most notable users are branch, daemon, submodule & worktree, and a worrisome call in transport.c when updating one ref (which ignores the shared flag). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-08Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"Libravatar Nguyễn Thái Ngọc Duy3-117/+5
This reverts commit 57534ee77d22e725d971ee89c77dc6aad61c573f. The feature added in that commit requires that patterns behave the same way from anywhere. But some patterns can behave differently depending on current "working" directory. The conditions to catch and avoid these patterns are too loose. The untracked listing[1] and sparse-checkout selection[2] can become incorrect as a result. [1] http://article.gmane.org/gmane.comp.version-control.git/283520 [2] http://article.gmane.org/gmane.comp.version-control.git/283532 Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-07commit: allow editing the commit message even in shared reposLibravatar Johannes Schindelin3-1/+15
It was pointed out by Yaroslav Halchenko that the file containing the commit message is writable only by the owner, which means that we have to rewrite it from scratch in a shared repository. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-05Expand documentation describing --signoffLibravatar David A. Wheeler5-1/+9
Modify various document (man page) files to explain in more detail what --signoff means. This was inspired by https://lwn.net/Articles/669976/ where paulj noted, "adding [the] '-s' argument to [a] git commit doesn't really mean you have even heard of the DCO...". Extending git's documentation will make it easier to argue that developers understood --signoff when they use it. Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-05reflog-walk: don't segfault on non-commit sha1's in the reflogLibravatar Dennis Kaarsemaker2-5/+24
git reflog (ab)uses the log machinery to display its list of log entries. To do so it must fake commit parent information for the log walker. For refs in refs/heads this is no problem, as they should only ever point to commits. Tags and other refs however can point to anything, thus their reflog may contain non-commit objects. To avoid segfaulting, we check whether reflog entries are commits before feeding them to the log walker and skip any non-commits. This means that git reflog output will be incomplete for such refs, but that's one step up from segfaulting. A more complete solution would be to decouple git reflog from the log walker machinery. Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net> Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-04Git 2.7Libravatar Junio C Hamano2-1/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-04Sync with 2.6.5Libravatar Junio C Hamano2-1/+21
2016-01-04Git 2.6.5Libravatar Junio C Hamano3-2/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-04Merge branch 'jk/pending-keep-tag-name' into maintLibravatar Junio C Hamano2-2/+30
History traversal with "git log --source" that starts with an annotated tag failed to report the tag as "source", due to an old regression in the command line parser back in v2.2 days. * jk/pending-keep-tag-name: revision.c: propagate tag names from pending array
2016-01-04Merge branch 'jk/symbolic-ref-maint' into maintLibravatar Junio C Hamano2-1/+23
"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()
2016-01-04Merge branch 'jk/ident-loosen-getpwuid' into maintLibravatar Junio C Hamano3-24/+40
When getpwuid() on the system returned NULL (e.g. the user is not in the /etc/passwd file or other uid-to-name mappings), the codepath to find who the user is to record it in the reflog barfed and died. Loosen the check in this codepath, which already accepts questionable ident string (e.g. host part of the e-mail address is obviously bogus), and in general when we operate fmt_ident() function in non-strict mode. * jk/ident-loosen-getpwuid: ident: loosen getpwuid error in non-strict mode ident: keep a flag for bogus default_email ident: make xgetpwuid_self() a static local helper
2016-01-04Merge branch 'jk/send-email-ssl-errors' into maintLibravatar Junio C Hamano1-0/+7
Improve error reporting when SMTP TLS fails. * jk/send-email-ssl-errors: send-email: enable SSL level 1 debug output