summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2017-01-26submodule absorbing: fix worktree/gitdir pointers recursively for non-movesLibravatar Stefan Beller1-0/+27
Consider having a submodule 'sub' and a nested submodule at 'sub/nested'. When nested is already absorbed into sub, but sub is not absorbed into its superproject, then we need to fixup the gitfile and core.worktree setting for 'nested' when absorbing 'sub', but we do not need to move its git dir around. Previously 'nested's gitfile contained "gitdir: ../.git/modules/nested"; it has to be corrected to "gitdir: ../../.git/modules/sub1/modules/nested". An alternative I considered to do this work lazily, i.e. when resolving "../.git/modules/nested", we would notice the ".git" being a gitfile linking to another path. That seemed to be robuster by design, but harder to get the implementation right. Maybe we have to do that anyway once we try to have submodules and worktrees working nicely together, but for now just produce 'correct' (i.e. direct) pointers. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23Merge branch 'sb/cd-then-git-can-be-written-as-git-c'Libravatar Junio C Hamano1-4/+1
Test clean-up. * sb/cd-then-git-can-be-written-as-git-c: lib-submodule-update.sh: reduce use of subshell by using "git -C"
2017-01-23Merge branch 'sg/fix-versioncmp-with-common-suffix'Libravatar Junio C Hamano1-20/+112
The prereleaseSuffix feature of version comparison that is used in "git tag -l" did not correctly when two or more prereleases for the same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2 are there and the code needs to compare 2.0-beta1 and 2.0-beta2). * sg/fix-versioncmp-with-common-suffix: versioncmp: generalize version sort suffix reordering versioncmp: factor out helper for suffix matching versioncmp: use earliest-longest contained suffix to determine sorting order versioncmp: cope with common part overlapping with prerelease suffix versioncmp: pass full tagnames to swap_prereleases() t7004-tag: add version sort tests to show prerelease reordering issues t7004-tag: use test_config helper t7004-tag: delete unnecessary tags with test_when_finished
2017-01-23Merge branch 'vn/diff-ihc-config'Libravatar Junio C Hamano1-1/+26
"git diff" learned diff.interHunkContext configuration variable that gives the default value for its --inter-hunk-context option. * vn/diff-ihc-config: diff: add interhunk context config option
2017-01-23Merge branch 'sb/submodule-init'Libravatar Junio C Hamano1-0/+17
Error message fix. * sb/submodule-init: submodule update --init: display correct path from submodule
2017-01-23Merge branch 'sb/submodule-config-tests'Libravatar Junio C Hamano1-2/+23
Test updates. * sb/submodule-config-tests: t7411: test lookup of uninitialized submodules t7411: quote URLs
2017-01-23Merge branch 'jk/grep-e-could-be-extended-beyond-posix'Libravatar Junio C Hamano1-11/+15
Tighten a test to avoid mistaking an extended ERE regexp engine as a PRE regexp engine. * jk/grep-e-could-be-extended-beyond-posix: t7810: avoid assumption about invalid regex syntax
2017-01-18Merge branch 'rh/mergetool-regression-fix'Libravatar Junio C Hamano1-114/+165
"git mergetool" without any pathspec on the command line that is run from a subdirectory became no-op in Git v2.11 by mistake, which has been fixed. * rh/mergetool-regression-fix: mergetool: fix running in subdir when rerere enabled mergetool: take the "-O" out of $orderfile t7610: add test case for rerere+mergetool+subdir bug t7610: spell 'git reset --hard' consistently t7610: don't assume the checked-out commit t7610: always work on a test-specific branch t7610: delete some now-unnecessary 'git reset --hard' lines t7610: run 'git reset --hard' after each test to clean up t7610: don't rely on state from previous test t7610: use test_when_finished for cleanup tasks t7610: move setup code to the 'setup' test case t7610: update branch names to match test number rev-parse doc: pass "--" to rev-parse in the --prefix example .mailmap: record canonical email for Richard Hansen
2017-01-18Merge branch 'sb/pathspec-errors'Libravatar Junio C Hamano1-0/+36
Running "git add a/b" when "a" is a submodule correctly errored out, but without a meaningful error message. * sb/pathspec-errors: pathspec: give better message for submodule related pathspec error
2017-01-18Merge branch 'pb/test-must-fail-is-for-git'Libravatar Junio C Hamano10-26/+26
Test cleanup. * pb/test-must-fail-is-for-git: t9813: avoid using pipes don't use test_must_fail with grep
2017-01-18Merge branch 'js/mingw-test-push-unc-path'Libravatar Junio C Hamano1-0/+48
"git push \\server\share\dir" has recently regressed and then fixed. A test has retroactively been added for this breakage. * js/mingw-test-push-unc-path: mingw: add a regression test for pushing to UNC paths
2017-01-18Merge branch 'km/branch-get-push-while-detached'Libravatar Junio C Hamano1-0/+6
"git <cmd> @{push}" on a detached HEAD used to segfault; it has been corrected to error out with a message. * km/branch-get-push-while-detached: branch_get_push: do not segfault when HEAD is detached
2017-01-18Merge branch 'jk/blame-fixes'Libravatar Junio C Hamano2-0/+149
"git blame --porcelain" misidentified the "previous" <commit, path> pair (aka "source") when contents came from two or more files. * jk/blame-fixes: blame: output porcelain "previous" header for each file blame: handle --no-abbrev blame: fix alignment with --abbrev=40
2017-01-18Merge branch 'jk/archive-zip-userdiff-config'Libravatar Junio C Hamano1-4/+18
"git archive" did not read the standard configuration files, and failed to notice a file that is marked as binary via the userdiff driver configuration. * jk/archive-zip-userdiff-config: archive-zip: load userdiff config
2017-01-18Merge branch 'dt/disable-bitmap-in-auto-gc'Libravatar Junio C Hamano2-5/+28
It is natural that "git gc --auto" may not attempt to pack everything into a single pack, and there is no point in warning when the user has configured the system to use the pack bitmap, leading to disabling further "gc". * dt/disable-bitmap-in-auto-gc: repack: die on incremental + write-bitmap-index auto gc: don't write bitmaps for incremental repacks
2017-01-18Merge branch 'sb/submodule-rm-absorb'Libravatar Junio C Hamano1-24/+15
"git rm" used to refuse to remove a submodule when it has its own git repository embedded in its working tree. It learned to move the repository away to $GIT_DIR/modules/ of the superproject instead, and allow the submodule to be deleted (as long as there will be no loss of local modifications, that is). * sb/submodule-rm-absorb: rm: absorb a submodules git dir before deletion submodule: rename and add flags to ok_to_remove_submodule submodule: modernize ok_to_remove_submodule to use argv_array submodule.h: add extern keyword to functions
2017-01-18Merge branch 'bw/grep-recurse-submodules'Libravatar Junio C Hamano1-0/+241
"git grep" has been taught to optionally recurse into submodules. * bw/grep-recurse-submodules: grep: search history of moved submodules grep: enable recurse-submodules to work on <tree> objects grep: optionally recurse into submodules grep: add submodules as a grep source type submodules: load gitmodules file from commit sha1 submodules: add helper to determine if a submodule is initialized submodules: add helper to determine if a submodule is populated real_path: canonicalize directory separators in root parts real_path: have callers use real_pathdup and strbuf_realpath real_path: create real_pathdup real_path: convert real_path_internal to strbuf_realpath real_path: resolve symlinks by hand
2017-01-13lib-submodule-update.sh: reduce use of subshell by using "git -C"Libravatar Stefan Beller1-4/+1
We write (cd <dir> && git <cmd>) to avoid cd <dir> && git <cmd> && cd .. that allows a breakage in one part of the test script to leave the entire test process in an unexpected place. Modern version of Git allows us to do this more concisely with "git -C <dir> <cmd>". Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-12submodule update --init: display correct path from submoduleLibravatar Stefan Beller1-0/+17
In the submodule helper we did not correctly handled the display path for initializing submodules when both the submodule is inside a subdirectory as well as the command being invoked from a subdirectory (as viewed from the superproject). This was broken in 3604242f080, which was written at a time where there was no super-prefix available, so we abused the --prefix option for the same purpose and could get only one case right (the call from within a subdirectory, not the submodule being in a subdirectory). Test-provided-by: David Turner <novalis@novalis.org> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-12t7411: test lookup of uninitialized submodulesLibravatar Stefan Beller1-0/+21
Sometimes we need to lookup information of uninitialized submodules. Make sure that works. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-12t7411: quote URLsLibravatar Stefan Beller1-2/+2
The variables may contain white spaces, so we need to quote them. By not quoting the variables we'd end up passing multiple arguments to git config, which doesn't fail for two arguments as value. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-12diff: add interhunk context config optionLibravatar Vegard Nossum1-1/+26
The --inter-hunk-context= option was added in commit 6d0e674a5754 ("diff: add option to show context between close hunks"). This patch allows configuring a default for this option. Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-12versioncmp: generalize version sort suffix reorderingLibravatar SZEDER Gábor1-0/+35
The 'versionsort.prereleaseSuffix' configuration variable, as its name suggests, is supposed to only deal with tagnames with prerelease suffixes, and allows sorting those prerelease tags in a user-defined order before the suffixless main release tag, instead of sorting them simply lexicographically. However, the previous changes in this series resulted in an interesting and useful property of version sort: - The empty string as a configured suffix matches all tagnames, including tagnames without any suffix, but - tagnames containing a "real" configured suffix are still ordered according to that real suffix, because any longer suffix takes precedence over the empty string. Exploiting this property we can easily generalize suffix reordering and specify the order of tags with given suffixes not only before but even after a main release tag by using the empty suffix to denote the position of the main release tag, without any algorithm changes: $ git -c versionsort.prereleaseSuffix=-alpha \ -c versionsort.prereleaseSuffix=-beta \ -c versionsort.prereleaseSuffix="" \ -c versionsort.prereleaseSuffix=-gamma \ -c versionsort.prereleaseSuffix=-delta \ tag -l --sort=version:refname 'v3.0*' v3.0-alpha1 v3.0-beta1 v3.0 v3.0-gamma1 v3.0-delta1 Since 'versionsort.prereleaseSuffix' is not a fitting name for a configuration variable to control this more general suffix reordering, introduce the new variable 'versionsort.suffix'. Still keep the old configuration variable name as a deprecated alias, though, to avoid suddenly breaking setups already using it. Ignore the old variable if both old and new configuration variables are set, but emit a warning so users will be aware of it and can fix their configuration. Extend the documentation to describe and add a test to check this more general behavior. Note: since the empty suffix matches all tagnames, tagnames with suffixes not included in the configuration are listed together with the suffixless main release tag, ordered lexicographically right after that, i.e. before tags with suffixes listed in the configuration following the empty suffix. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-11t7810: avoid assumption about invalid regex syntaxLibravatar Jeff King1-11/+15
A few of the tests want to check that "git grep -P -E" will override -P with -E, and vice versa. To do so, we use a regex with "\x{..}", which is valid in PCRE but not defined by POSIX (for basic or extended regular expressions). However, POSIX declares quite a lot of syntax, including "\x", as "undefined". That leaves implementations free to extend the standard if they choose. At least one, musl libc, implements "\x" in the same way as PCRE. Our tests check that "-E" complains about "\x", which fails with musl. We can fix this by finding some construct which behaves reliably on both PCRE and POSIX, but differently in each system. One such construct is the use of backslash inside brackets. In PCRE, "[\d]" interprets "\d" as it would outside the brackets, matching a digit. Whereas in POSIX, the backslash must be treated literally, and we match either it or a literal "d". Moreover, implementations are not free to change this according to POSIX, so we should be able to rely on it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10Merge branch 'sb/submodule-embed-gitdir'Libravatar Junio C Hamano2-5/+116
A new submodule helper "git submodule embedgitdirs" to make it easier to move embedded .git/ directory for submodules in a superproject to .git/modules/ (and point the latter with the former that is turned into a "gitdir:" file) has been added. * sb/submodule-embed-gitdir: worktree: initialize return value for submodule_uses_worktrees submodule: add absorb-git-dir function move connect_work_tree_and_git_dir to dir.h worktree: check if a submodule uses worktrees test-lib-functions.sh: teach test_commit -C <dir> submodule helper: support super prefix submodule: use absolute path for computing relative path connecting
2017-01-10Merge branch 'mh/fast-import-notes-fix-new'Libravatar Junio C Hamano1-0/+42
"git fast-import" sometimes mishandled while rebalancing notes tree, which has been fixed. * mh/fast-import-notes-fix-new: fast-import: properly fanout notes when tree is imported
2017-01-10Merge branch 'jc/compression-config'Libravatar Junio C Hamano3-0/+140
Compression setting for producing packfiles were spread across three codepaths, one of which did not honor any configuration. Unify these so that all of them honor core.compression and pack.compression variables the same way. * jc/compression-config: compression: unify pack.compression configuration parsing
2017-01-10Merge branch 'dt/smart-http-detect-server-going-away'Libravatar Junio C Hamano1-0/+52
When the http server gives an incomplete response to a smart-http rpc call, it could lead to client waiting for a full response that will never come. Teach the client side to notice this condition and abort the transfer. An improvement counterproposal has failed. cf. <20161114194049.mktpsvgdhex2f4zv@sigill.intra.peff.net> * dt/smart-http-detect-server-going-away: upload-pack: optionally allow fetching any sha1 remote-curl: don't hang when a server dies before any output
2017-01-10mergetool: fix running in subdir when rerere enabledLibravatar Richard Hansen1-1/+6
"git mergetool" (without any pathspec on the command line) that is not run from the top-level of the working tree no longer works in Git v2.11, failing to get the list of unmerged paths from the output of "git rerere remaining". This regression was introduced by 57937f70a0 ("mergetool: honor diff.orderFile", 2016-10-07). This is because the pathnames output by the 'git rerere remaining' command are relative to the top-level directory but the 'git diff --name-only' command expects its pathname arguments to be relative to the current working directory. To make everything consistent, cd_to_toplevel before running 'git diff --name-only' and adjust any relative pathnames. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: add test case for rerere+mergetool+subdir bugLibravatar Richard Hansen1-1/+20
If rerere is enabled and mergetool is run from a subdirectory, mergetool always prints "No files need merging". Add an expected failure test case for this situation. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: spell 'git reset --hard' consistentlyLibravatar Richard Hansen1-18/+19
Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: don't assume the checked-out commitLibravatar Richard Hansen1-6/+6
Always check out the required commit at the beginning of the test so that a failure in a previous test does not cause the test to work off of the wrong commit. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: always work on a test-specific branchLibravatar Richard Hansen1-2/+8
Create and use a test-specific branch when the test might create a commit. This is not always necessary for correctness, but it improves debuggability by ensuring a commit created by test #N shows up on the testN branch, not the branch for test #N-1. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: delete some now-unnecessary 'git reset --hard' linesLibravatar Richard Hansen1-2/+0
Tests now always run 'git reset --hard' at the end (even if they fail), so it's no longer necessary to run 'git reset --hard' at the beginning of a test. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: run 'git reset --hard' after each test to clean upLibravatar Richard Hansen1-0/+8
Use test_when_finished to run 'git reset --hard' after each test so that the repository is left in a saner state for the next test. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: don't rely on state from previous testLibravatar Richard Hansen1-0/+6
If the repository must be in a particular state (beyond what is already done by the 'setup' test case) before the test can run, make the necessary repository changes in the test script even if it means duplicating some lines of code from the previous test case. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: use test_when_finished for cleanup tasksLibravatar Richard Hansen1-34/+37
This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: move setup code to the 'setup' test caseLibravatar Richard Hansen1-30/+35
Multiple test cases depend on these hunks, so move them to the 'setup' test case. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: update branch names to match test numberLibravatar Richard Hansen1-41/+41
Rename the testNN branches so that NN matches the test number. This should make it easier to troubleshoot test issues. Use $test_count to keep this future-proof. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-09pathspec: give better message for submodule related pathspec errorLibravatar Stefan Beller1-0/+36
Every once in a while someone complains to the mailing list to have run into this weird assertion[1]. The usual response from the mailing list is link to old discussions[2], and acknowledging the problem stating it is known. This patch accomplishes two things: 1. Switch assert() to die("BUG") to give a more readable message. 2. Take one of the cases where we hit a BUG and turn it into a normal "there was something wrong with the input" message. This assertion triggered for cases where there wasn't a programming bug, but just bogus input. In particular, if the user asks for a pathspec that is inside a submodule, we shouldn't assert() or die("BUG"); we should tell the user their request is bogus. The only reason we did not check for it, is the expensive nature of such a check, so callers avoid setting the flag PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE. However when we die due to bogus input, the expense of CPU cycles spent outweighs the user wondering what went wrong, so run that check unconditionally before dying with a more generic error message. Note: There is a case (e.g. "git -C submodule add .") in which we call strip_submodule_slash_expensive, as git-add requests it via the flag PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE, but the assert used to trigger nevertheless, because the flag PATHSPEC_LITERAL was not set, such that we executed if (item->nowildcard_len < prefixlen) item->nowildcard_len = prefixlen; and prefixlen was not adapted (e.g. it was computed from "submodule/") So in the die_inside_submodule_path function we also need handle paths, that were stripped before, i.e. are the exact submodule path. This is why the conditions in die_inside_submodule_path are slightly different than in strip_submodule_slash_expensive. [1] https://www.google.com/search?q=item-%3Enowildcard_len [2] http://git.661346.n2.nabble.com/assert-failed-in-submodule-edge-case-td7628687.html https://www.spinics.net/lists/git/msg249473.html Helped-by: Jeff King <peff@peff.net> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-09t9813: avoid using pipesLibravatar Pranit Bauva1-4/+4
The exit code of the upstream in a pipe is ignored thus we should avoid using it. By writing out the output of the git command to a file, we can test the exit codes of both the commands. Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07blame: output porcelain "previous" header for each fileLibravatar Jeff King1-0/+117
It's possible for content currently found in one file to have originated in two separate files, each of which may have been modified in some single older commit. The --porcelain output generates an incorrect "previous" header in this case, whereas --line-porcelain gets it right. The problem is that the porcelain output tries to omit repeated details of commits, and treats "previous" as a property of the commit, when it is really a property of the blamed block of lines. Let's look at an example. In a case like this, you might see this output from --line-porcelain: SOME_SHA1 1 1 1 author ... committer ... previous SOME_SHA1^ file_one filename file_one ...some line content... SOME_SHA1 2 1 1 author ... committer ... previous SOME_SHA1^ file_two filename file_two ...some different content.... The "filename" fields tell us that the two lines are from two different files. But notice that the filename also appears in the "previous" field, which tells us where to start a re-blame. The second content line never appeared in file_one at all, so we would obviously need to re-blame from file_two (or possibly even some other file, if had just been renamed to file_two in SOME_SHA1). So far so good. Now here's what --porcelain looks like: SOME_SHA1 1 1 1 author ... committer ... previous SOME_SHA1^ file_one filename file_one ...some line content... SOME_SHA1 2 1 1 filename file_two ...some different content.... We've dropped the author and committer fields from the second line, as they would just be repeats. But we can't omit "filename", because it depends on the actual block of blamed lines, not just the commit. This is handled by emit_porcelain_details(), which will show the filename either if it is the first mention of the commit _or_ if the commit has multiple paths in it. But we don't give "previous" the same handling. It's written inside emit_one_suspect_detail(), which bails early if we've already seen that commit. And so the output above is wrong; a reader would assume that the correct place to re-blame line two is from file_one, but that's obviously nonsense. Let's treat "previous" the same as "filename", and show it fresh whenever we know we are in a confusing case like this. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07blame: handle --no-abbrevLibravatar Jeff King1-0/+4
You can already ask blame for full sha1s with "-l" or with "--abbrev=40". But for consistency with other parts of Git, we should support "--no-abbrev". Worse, blame already accepts --no-abbrev, but it's totally broken. When we see --no-abbrev, the abbrev variable is set to 0, which is then used as a printf precision. For regular sha1s, that means we print nothing at all (which is very wrong). For boundary commits we decrement it to "-1", which printf interprets as "no limit" (which is almost correct, except it misses the 39-length magic explained in the previous commit). Let's detect --no-abbrev and behave as if --abbrev=40 was given. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07blame: fix alignment with --abbrev=40Libravatar Jeff King1-0/+28
The blame command internally adds 1 to any requested sha1 abbreviation length, and then subtracts it when outputting a boundary commit. This lets regular and boundary sha1s line up visually, but it misses one corner case. When the requested length is 40, we bump the value to 41. But since we only have 40 characters, that's all we can show (fortunately the truncation is done by a printf precision field, so it never tries to read past the end of the buffer). So a normal sha1 shows 40 hex characters, and a boundary sha1 shows "^" plus 40 hex characters. The result is misaligned. The "-l" option to show long sha1s gets around this by skipping the "abbrev" variable entirely and just always using GIT_SHA1_HEXSZ. This avoids the "+1" issue, but it does mean that boundary commits only have 39 characters printed. This is somewhat odd, but it does look good visually: the results are aligned and left-justified. The alternative would be to allocate an extra column that would contain either an extra space or the "^" boundary marker. As this is by definition the human-readable view, it's probably not that big a deal either way (and of course --porcelain, etc, correctly produce correct 40-hex sha1s). But for consistency, this patch teaches --abbrev=40 to produce the same output as "-l" (always left-aligned, with 40-hex for normal sha1s, and "^" plus 39-hex for boundaries). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07branch_get_push: do not segfault when HEAD is detachedLibravatar Kyle Meyer1-0/+6
Move the detached HEAD check from branch_get_push_1() to branch_get_push() to avoid setting branch->push_tracking_ref when branch is NULL. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07archive-zip: load userdiff configLibravatar Jeff King1-4/+18
Since 4aff646d17 (archive-zip: mark text files in archives, 2015-03-05), the zip archiver will look at the userdiff driver to decide whether a file is text or binary. This usually doesn't need to look any further than the attributes themselves (e.g., "-diff", etc). But if the user defines a custom driver like "diff=foo", we need to look at "diff.foo.binary" in the config. Prior to this patch, we didn't actually load it. Signed-off-by: Jeff King <peff@peff.net> Acked-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07mingw: add a regression test for pushing to UNC pathsLibravatar Johannes Schindelin1-0/+48
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does, as reported here: https://github.com/git-for-windows/git/issues/979 This regression was fixed in 7814fbe3f1 (normalize_path_copy(): fix pushing to //server/share/dir on Windows, 2016-12-14). Let's make sure that it does not regress again, by introducing a test that uses so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07don't use test_must_fail with grepLibravatar Pranit Bauva10-22/+22
test_must_fail should only be used for testing git commands. To test the failure of other commands use `!`. Reported-by: Stefan Beller <sbeller@google.com> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-29repack: die on incremental + write-bitmap-indexLibravatar David Turner1-5/+3
The bitmap index only works for single packs, so requesting an incremental repack with bitmap indexes makes no sense. Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-29auto gc: don't write bitmaps for incremental repacksLibravatar David Turner1-0/+25
When git gc --auto does an incremental repack of loose objects, we do not expect to be able to write a bitmap; it is very likely that objects in the new pack will have references to objects outside of the pack. So we shouldn't try to write a bitmap, because doing so will likely issue a warning. This warning was making its way into gc.log. When the gc.log was present, future auto gc runs would refuse to run. Patch by Jeff King. Bug report, test, and commit message by David Turner. Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>