summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2017-12-06Merge branch 'tz/redirect-fix' into maintLibravatar Junio C Hamano1-1/+1
A few scripts (both in production and tests) incorrectly redirected their error output. These have been corrected. * tz/redirect-fix: rebase: fix stderr redirect in apply_autostash() t/lib-gpg: fix gpgconf stderr redirect to /dev/null
2017-12-06Merge branch 'tz/notes-error-to-stderr' into maintLibravatar Junio C Hamano2-5/+5
"git notes" sent its error message to its standard output stream, which was corrected. * tz/notes-error-to-stderr: notes: send "Automatic notes merge failed" messages to stderr
2017-12-06Merge branch 'sb/test-cherry-pick-submodule-getting-in-a-way' into maintLibravatar Junio C Hamano1-0/+36
The three-way merge performed by "git cherry-pick" was confused when a new submodule was added in the meantime, which has been fixed (or "papered over"). * sb/test-cherry-pick-submodule-getting-in-a-way: merge-recursive: handle addition of submodule on our side of history t/3512: demonstrate unrelated submodule/file conflict as cherry-pick failure
2017-12-06Merge branch 'rs/apply-inaccurate-eof-with-incomplete-line' into maintLibravatar Junio C Hamano1-0/+14
"git apply --inaccurate-eof" when used with "--ignore-space-change" triggered an internal sanity check, which has been fixed. * rs/apply-inaccurate-eof-with-incomplete-line: apply: update line lengths for --inaccurate-eof
2017-12-06Merge branch 'ew/rebase-mboxrd' into maintLibravatar Junio C Hamano1-0/+22
When "git rebase" prepared an mailbox of changes and fed it to "git am" to replay them, it was confused when a stray "From " happened to be in the log message of one of the replayed changes. This has been corrected. * ew/rebase-mboxrd: rebase: use mboxrd format to avoid split errors
2017-12-06Merge branch 'mh/avoid-rewriting-packed-refs' into maintLibravatar Junio C Hamano1-0/+118
Recent update to the refs infrastructure implementation started rewriting packed-refs file more often than before; this has been optimized again for most trivial cases. * mh/avoid-rewriting-packed-refs: files-backend: don't rewrite the `packed-refs` file unnecessarily t1409: check that `packed-refs` is not rewritten unnecessarily
2017-11-21Merge branch 'cb/t4201-robustify' into maintLibravatar Junio C Hamano2-5/+7
A test update. * cb/t4201-robustify: t4201: make use of abbreviation in the test more robust
2017-11-21Merge branch 'tz/fsf-address-update' into maintLibravatar Junio C Hamano1-3/+1
Replace the mailing address of FSF to a URL, as FSF prefers. * tz/fsf-address-update: Replace Free Software Foundation address in license notices Replace Free Software Foundation address in license notices
2017-11-21Merge branch 'sr/wrapper-quote-filenames' into maintLibravatar Junio C Hamano2-2/+2
Some error messages did not quote filenames shown in it, which have been fixed. * sr/wrapper-quote-filenames: wrapper.c: consistently quote filenames in error messages
2017-11-21Merge branch 'bw/rebase-i-ignored-submodule-fix' into maintLibravatar Junio C Hamano1-0/+17
"git rebase -i" recently started misbehaving when a submodule that is configured with 'submodule.<name>.ignore' is dirty; this has been corrected. * bw/rebase-i-ignored-submodule-fix: wt-status: actually ignore submodules when requested
2017-11-18rebase: use mboxrd format to avoid split errorsLibravatar Eric Wong1-0/+22
The mboxrd format allows the use of embedded "From " lines in commit messages without being misinterpreted by mailsplit Reported-by: Florian Weimer <fweimer@redhat.com> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-17apply: update line lengths for --inaccurate-eofLibravatar René Scharfe1-0/+14
Some diff implementations don't report missing newlines at the end of files. Applying such a patch can cause a newline character to be added inadvertently. The option --inaccurate-eof of git apply can be used to remove trailing newlines if needed. apply_one_fragment() cuts it off from the buffers for preimage and postimage. Before it does, it builds an array with the lengths of each line for both. Make sure to update the length of the last line in these line info structures as well to keep them consistent with their respective buffer. Without this fix the added test fails; git apply dies and reports: fatal: BUG: caller miscounted postlen: asked 1, orig = 1, used = 2 That sanity check is only called if whitespace changes are ignored. Reported-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-15merge-recursive: handle addition of submodule on our side of historyLibravatar Elijah Newren1-1/+1
The code for a newly added path assumed that the path was a normal file, and thus checked for there being a directory still being in the way of the file. Note that since unpack_trees() does path-in-the-way checks already, the only way for there to be a directory in the way at this point in the code, is if there is some kind of D/F conflict in the merge. For a submodule addition on HEAD's side of history, the submodule would have already been present. This means that we do expect there to be a directory present but should not consider it to be "in the way"; instead, it's the expected submodule. So, when there's a submodule addition from HEAD's side, don't bother checking the working copy for a directory in the way. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-15Merge branch 'js/mingw-redirect-std-handles' into maintLibravatar Junio C Hamano1-0/+12
MinGW updates. * js/mingw-redirect-std-handles: mingw: document the standard handle redirection mingw: optionally redirect stderr/stdout via the same handle mingw: add experimental feature to redirect standard handles
2017-11-15Merge branch 'js/wincred-empty-cred' into maintLibravatar Junio C Hamano1-0/+19
MinGW updates. * js/wincred-empty-cred: wincred: handle empty username/password correctly t0302: check helper can handle empty credentials
2017-11-15Merge branch 'ad/5580-unc-tests-on-cygwin' into maintLibravatar Junio C Hamano1-4/+10
UNC paths are also relevant in Cygwin builds and they are now tested just like Mingw builds. * ad/5580-unc-tests-on-cygwin: t5580: add Cygwin support
2017-11-15Merge branch 'tb/complete-checkout' into maintLibravatar Junio C Hamano1-0/+4
Command line completion (in contrib/) update. * tb/complete-checkout: completion: add remaining flags to checkout
2017-11-15Merge branch 'jc/check-ref-format-oor' into maintLibravatar Junio C Hamano1-0/+16
"git check-ref-format --branch @{-1}" bit a "BUG()" when run outside a repository for obvious reasons; clarify the documentation and make sure we do not even try to expand the at-mark magic in such a case, but still call the validation logic for branch names. * jc/check-ref-format-oor: check-ref-format doc: --branch validates and expands <branch> check-ref-format --branch: strip refs/heads/ using skip_prefix check-ref-format --branch: do not expand @{...} outside repository
2017-11-15Merge branch 'jc/t5601-copy-workaround' into maintLibravatar Junio C Hamano1-0/+2
A (possibly flakey) test fix. * jc/t5601-copy-workaround: t5601: rm the target file of cp that could still be executing
2017-11-15Merge branch 'jk/rebase-i-exec-gitdir-fix' into maintLibravatar Junio C Hamano1-0/+11
A recent regression in "git rebase -i" that broke execution of git commands from subdirectories via "exec" insn has been fixed. * jk/rebase-i-exec-gitdir-fix: sequencer: pass absolute GIT_DIR to exec commands
2017-11-15Merge branch 'js/submodule-in-excluded' into maintLibravatar Junio C Hamano1-0/+11
"git status --ignored -u" did not stop at a working tree of a separate project that is embedded in an ignored directory and listed files in that other project, instead of just showing the directory itself as ignored. * js/submodule-in-excluded: status: do not get confused by submodules in excluded directories
2017-11-15Merge branch 'jk/misc-resolve-ref-unsafe-fixes' into maintLibravatar Junio C Hamano1-1/+1
Some codepaths did not check for errors when asking what branch the HEAD points at, which have been fixed. * jk/misc-resolve-ref-unsafe-fixes: worktree: handle broken symrefs in find_shared_symref() log: handle broken HEAD in decoration check remote: handle broken symrefs test-ref-store: avoid passing NULL to printf
2017-11-15Merge branch 'jk/diff-color-moved-fix' into maintLibravatar Junio C Hamano1-36/+177
The experimental "color moved lines differently in diff output" feature was buggy around "ignore whitespace changes" edges, whihch has been corrected. * jk/diff-color-moved-fix: diff: handle NULs in get_string_hash() diff: fix whitespace-skipping with --color-moved t4015: test the output of "diff --color-moved -b" t4015: check "negative" case for "-w --color-moved" t4015: refactor --color-moved whitespace test
2017-11-15Merge branch 'kd/auto-col-with-pager-fix' into maintLibravatar Junio C Hamano1-0/+14
"auto" as a value for the columnar output configuration ought to judge "is the output consumed by humans?" with the same criteria as "auto" for coloured output configuration, i.e. either the standard output stream is going to tty, or a pager is in use. We forgot the latter, which has been fixed. * kd/auto-col-with-pager-fix: column: do not include pager.c column: show auto columns when pager is active
2017-11-15notes: send "Automatic notes merge failed" messages to stderrLibravatar Todd Zullinger2-5/+5
All other error messages from notes use stderr. Do the same when alerting users of an unresolved notes merge. Fix the output redirection in t3310 and t3320 as well. Previously, the tests directed output to a file, but stderr was either not captured or not sent to the file due to the order of the redirection operators. Signed-off-by: Todd Zullinger <tmz@pobox.com> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-14t/lib-gpg: fix gpgconf stderr redirect to /dev/nullLibravatar Todd Zullinger1-1/+1
In 29ff1f8f74 (t: lib-gpg: flush gpg agent on startup, 2017-07-20), a call to gpgconf was added to kill the gpg-agent. The intention was to ignore all output from the call, but the order of the redirection needs to be switched to ensure that both stdout and stderr are redirected to /dev/null. Without this, gpgconf from gnupg-2.0 releases would output 'gpgconf: invalid option "--kill"' each time it was called. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-13t4201: make use of abbreviation in the test more robustLibravatar Charles Bailey2-5/+7
The test for '--abbrev' in t4201-shortlog.sh assumes that the commits generated in the test can always be uniquely abbreviated to 5 hex digits but this is not always the case. If you were unlucky and happened to run the test at (say) Thu Jun 22 03:04:49 2017 +0000, you would find that the first commit generated would collide with a tree object created later in the same test. This can be simulated in the version of t4201-shortlog.sh prior to this commit by setting GIT_COMMITTER_DATE and GIT_AUTHOR_DATE to 1498100689 after sourcing test-lib.sh. Change the test to test --abbrev=35 instead of --abbrev=5 to almost completely avoid the possibility of a partial collision and add a call to test_tick in the setup to make the test repeatable (the latter alone is sufficient to make it robust enough). Signed-off-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-12t/3512: demonstrate unrelated submodule/file conflict as cherry-pick failureLibravatar Stefan Beller1-0/+36
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-09Replace Free Software Foundation address in license noticesLibravatar Todd Zullinger1-3/+1
The mailing address for the FSF has changed over the years. Rather than updating the address across all files, refer readers to gnu.org, as the GNU GPL documentation now suggests for license notices. The mailing address is retained in the full license files (COPYING and LGPL-2.1). The old address is still present in t/diff-lib/COPYING. This is intentional, as the file is used in tests and the contents are not expected to change. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-07wt-status: actually ignore submodules when requestedLibravatar Brandon Williams1-0/+17
Since ff6f1f564 (submodule-config: lazy-load a repository's .gitmodules file, 2017-08-03) rebase interactive fails if there are any submodules with unstaged changes which have been configured with a value for 'submodule.<name>.ignore' in the repository's config. This is due to how configured values of 'submodule.<name>.ignore' are handled in addition to a change in how the submodule config is loaded. When the diff machinery hits a submodule (gitlink as well as a corresponding entry in the submodule subsystem) it will read the value of 'submodule.<name>.ignore' stored in the repository's config and if the config is present it will clear the 'IGNORE_SUBMODULES' (which is the flag explicitly requested by rebase interactive), 'IGNORE_UNTRACKED_IN_SUBMODULES', and 'IGNORE_DIRTY_SUBMODULES' diff flags and then set one of them based on the configured value. Historically this wasn't a problem because the submodule subsystem wasn't initialized because the .gitmodules file wasn't explicitly loaded by the rebase interactive command. So when the diff machinery hit a submodule it would skip over reading any configured values of 'submodule.<name>.ignore'. In order to preserve the behavior of submodules being ignored by rebase interactive, also set the 'OVERRIDE_SUBMODULE_CONFIG' diff flag when submodules are requested to be ignored when checking for unstaged changes. Reported-by: Orgad Shaneh <orgads@gmail.com> Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06wrapper.c: consistently quote filenames in error messagesLibravatar Simon Ruderich2-2/+2
All other error messages in the file use quotes around the file name. This change removes two translations as "could not write to '%s'" and "could not close '%s'" are already translated and these two are the only occurrences without quotes. Signed-off-by: Simon Ruderich <simon@ruderich.org> [jc: adjusted tests I noticed were broken by the change] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-02mingw: optionally redirect stderr/stdout via the same handleLibravatar Johannes Schindelin1-1/+7
The "2>&1" notation in Powershell and in Unix shells implies that stderr is redirected to the same handle into which stdout is already written. Let's use this special value to allow the same trick with GIT_REDIRECT_STDERR and GIT_REDIRECT_STDOUT: if the former's value is `2>&1`, then stderr will simply be written to the same handle as stdout. The functionality was suggested by Jeff Hostetler. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-02mingw: add experimental feature to redirect standard handlesLibravatar Johannes Schindelin1-0/+6
Particularly when calling Git from applications, such as Visual Studio's Team Explorer, it is important that stdin/stdout/stderr are closed properly. However, when spawning processes on Windows, those handles must be marked as inheritable if we want to use them, but that flag is a global flag and may very well be used by other spawned processes which then do not know to close those handles. Let's introduce a set of environment variables (GIT_REDIRECT_STDIN and friends) that specify paths to files, or even better, named pipes (which are similar to Unix sockets) and that are used by the spawned Git process. This helps work around above-mentioned issue: those named pipes will be opened in a non-inheritable way upon startup, and no handles are passed around (and therefore no inherited handles need to be closed by any spawned child). This feature shipped with Git for Windows (marked as experimental) since v2.11.0(2), so it has seen some serious testing in the meantime. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-02sequencer: pass absolute GIT_DIR to exec commandsLibravatar Jacob Keller1-0/+11
When we replaced the old shell script based interactive rebase in commmit 18633e1a22a6 ("rebase -i: use the rebase--helper builtin", 2017-02-09) we introduced a regression of functionality in that the GIT_DIR would be sent to the environment of the exec command as-is. This generally meant that it would be passed as "GIT_DIR=.git", which causes problems for any exec command that wants to run git commands in a subdirectory. This isn't a very large regression, since it is not that likely that the exec command will run a git command, and even less likely that it will need to do so in a subdir. This regression was discovered by a build system which uses git-describe to find the current version of the build system, and happened to do so from the src/ sub directory of the project. Fix this by passing in the absolute path of the git directory into the child environment. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-01t0302: check helper can handle empty credentialsLibravatar Jakub Bereżański1-0/+19
Make sure the helper does not crash when blank username and password is provided. If the helper can save such credentials, it should be able to read them back. Signed-off-by: Jakub Bereżański <kuba@berezanscy.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-01t5580: add Cygwin supportLibravatar Adam Dinwoodie1-4/+10
t5580 tests that specifying Windows UNC paths works with Git. Cygwin supports UNC paths, albeit only using forward slashes, not backslashes, so run the compatible tests on Cygwin as well as MinGW. The only complication is Cygwin's `pwd`, which returns a *nix-style path, and that's not suitable for calculating the UNC path to the current directory. Instead use Cygwin's `cygpath` utility to get the Windows-style path. Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-30files-backend: don't rewrite the `packed-refs` file unnecessarilyLibravatar Michael Haggerty1-2/+2
Even when we are deleting references, we needn't overwrite the `packed-refs` file if the references that we are deleting only exist as loose references. Implement this optimization as follows: * Add a function `is_packed_transaction_needed()`, which checks whether a given packed-refs transaction actually needs to be carried out (i.e., it returns false if the transaction obviously wouldn't have any effect). This function must be called while holding the `packed-refs` lock to avoid races. * Change `files_transaction_prepare()` to check whether the packed-refs transaction is actually needed. If not, squelch it, but continue holding the `packed-refs` lock until the end of the transaction to avoid races. This fixes a mild regression caused by dc39e09942 (files_ref_store: use a transaction to update packed refs, 2017-09-08). Before that commit, unnecessary rewrites of `packed-refs` were suppressed by `repack_without_refs()`. But the transaction-based writing introduced by that commit didn't perform that optimization. Note that the pre-dc39e09942 code still had to *read* the whole `packed-refs` file to determine that the rewrite could be skipped, so the performance for the cases that the write could be elided was `O(N)` in the number of packed references both before and after dc39e09942. But after that commit the constant factor increased. This commit reimplements the optimization of eliding unnecessary `packed-refs` rewrites. That, plus the fact that since cfa2e29c34 (packed_ref_store: get rid of the `ref_cache` entirely, 2017-03-17) we don't necessarily have to read the whole `packed-refs` file at all, means that deletes of one or a few loose references can now be done with `O(n lg N)` effort, where `n` is the number of loose references being deleted and `N` is the total number of packed references. This commit fixes two tests in t1409. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-27t1409: check that `packed-refs` is not rewritten unnecessarilyLibravatar Michael Haggerty1-0/+118
There is no need to rewrite the `packed-refs` file except for the case that we are deleting a reference that has a packed version. Verify that `packed-refs` is not rewritten when it shouldn't be. In fact, two of these tests fail: * A new (empty) `packed-refs` file is created when deleting any loose reference and no `packed-refs` file previously existed. * The `packed-refs` file is rewritten unnecessarily when deleting a loose reference that has no packed counterpart. Both problems will be fixed in the next commit. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-26Merge branch 'mh/ref-locking-fix'Libravatar Junio C Hamano1-0/+141
Transactions to update multiple references that involves a deletion was quite broken in an error codepath and did not abort everything correctly. * mh/ref-locking-fix: files_transaction_prepare(): fix handling of ref lock failure t1404: add a bunch of tests of D/F conflicts
2017-10-26status: do not get confused by submodules in excluded directoriesLibravatar Johannes Schindelin1-0/+11
We meticulously pass the `exclude` flag to the `treat_directory()` function so that we can indicate that files in it are excluded rather than untracked when recursing. But we did not yet treat submodules the same way. Because of that, `git status --ignored --untracked` with a submodule `submodule` in a gitignored `tracked/` would show the submodule in the "Untracked files" section, e.g. On branch master Untracked files: (use "git add <file>..." to include in what will be committed) tracked/submodule/ Ignored files: (use "git add -f <file>..." to include in what will be committed) tracked/submodule/initial.t Instead, we would want it to show the submodule in the "Ignored files" section: On branch master Ignored files: (use "git add -f <file>..." to include in what will be committed) tracked/submodule/ Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-25completion: add remaining flags to checkoutLibravatar Thomas Braun1-0/+4
In the commits 1fc458d9 (builtin/checkout: add --recurse-submodules switch, 2017-03-14), 08d595dc (checkout: add --ignore-skip-worktree-bits in sparse checkout mode, 2013-04-13) and 32669671 (checkout: introduce --detach synonym for "git checkout foo^{commit}", 2011-02-08) checkout gained new flags but the completion was not updated, although these flags are useful completions. Add them. The flags --force and --ignore-other-worktrees are not added as they are potentially dangerous. The flags --progress and --no-progress are only useful for scripting and are therefore also not included. Signed-off-by: Thomas Braun <thomas.braun@virtuell-zuhause.de> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-25files_transaction_prepare(): fix handling of ref lock failureLibravatar Michael Haggerty1-8/+8
Since dc39e09942 (files_ref_store: use a transaction to update packed refs, 2017-09-08), failure to lock a reference has been handled incorrectly by `files_transaction_prepare()`. If `lock_ref_for_update()` fails in the lock-acquisition loop of that function, it sets `ret` then breaks out of that loop. Prior to dc39e09942, that was OK, because the only thing following the loop was the cleanup code. But dc39e09942 added another blurb of code between the loop and the cleanup. That blurb sometimes resets `ret` to zero, making the cleanup code think that the locking was successful. Specifically, whenever * One or more reference deletions have been processed successfully in the lock-acquisition loop. (Processing the first such reference causes a packed-ref transaction to be initialized.) * Then `lock_ref_for_update()` fails for a subsequent reference. Such a failure can happen for a number of reasons, such as the old SHA-1 not being correct, lock contention, etc. This causes a `break` out of the lock-acquisition loop. * The `packed-refs` lock is acquired successfully and `ref_transaction_prepare()` succeeds for the packed-ref transaction. This has the effect of resetting `ret` back to 0, and making the cleanup code think that lock acquisition was successful. In that case, any reference updates that were processed prior to breaking out of the loop would be carried out (loose and packed), but the reference that couldn't be locked and any subsequent references would silently be ignored. This can easily cause data loss if, for example, the user was trying to push a new name for an existing branch while deleting the old name. After the push, the branch could be left unreachable, and could even subsequently be garbage-collected. This problem was noticed in the context of deleting one reference and creating another in a single transaction, when the two references D/F conflict with each other, like git update-ref --stdin <<EOF delete refs/foo create refs/foo/bar HEAD EOF This triggers the above bug because the deletion is processed successfully for `refs/foo`, then the D/F conflict causes `lock_ref_for_update()` to fail when `refs/foo/bar` is processed. In this case the transaction *should* fail, but instead it causes `refs/foo` to be deleted without creating `refs/foo`. This could easily result in data loss. The fix is simple: instead of just breaking out of the loop, jump directly to the cleanup code. This fixes some tests in t1404 that were added in the previous commit. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-25t1404: add a bunch of tests of D/F conflictsLibravatar Michael Haggerty1-0/+141
It is currently not allowed, in a single transaction, to add one reference and delete another reference if the two reference names D/F conflict with each other (e.g., like `refs/foo/bar` and `refs/foo`). The reason is that the code would need to take locks $GIT_DIR/refs/foo.lock $GIT_DIR/refs/foo/bar.lock But the latter lock couldn't coexist with the loose reference file $GIT_DIR/refs/foo , because `$GIT_DIR/refs/foo` cannot be both a directory and a file at the same time (hence the name "D/F conflict). Add a bunch of tests that we cleanly reject such transactions. In fact, many of the new tests currently fail. They will be fixed in the next commit along with an explanation. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-23Merge branch 'jk/write-in-full-fix' into maintLibravatar Junio C Hamano1-1/+1
Many codepaths did not diagnose write failures correctly when disks go full, due to their misuse of write_in_full() helper function, which have been corrected. * jk/write-in-full-fix: read_pack_header: handle signed/unsigned comparison in read result config: flip return value of store_write_*() notes-merge: use ssize_t for write_in_full() return value pkt-line: check write_in_full() errors against "< 0" convert less-trivial versions of "write_in_full() != len" avoid "write_in_full(fd, buf, len) != len" pattern get-tar-commit-id: check write_in_full() return against 0 config: avoid "write_in_full(fd, buf, len) < len" pattern
2017-10-23Merge branch 'er/fast-import-dump-refs-on-checkpoint' into maintLibravatar Junio C Hamano1-0/+142
The checkpoint command "git fast-import" did not flush updates to refs and marks unless at least one object was created since the last checkpoint, which has been corrected, as these things can happen without any new object getting created. * er/fast-import-dump-refs-on-checkpoint: fast-import: checkpoint: dump branches/tags/marks even if object_count==0
2017-10-23Merge branch 'jt/fast-export-copy-modify-fix' into maintLibravatar Junio C Hamano1-1/+19
"git fast-export" with -M/-C option issued "copy" instruction on a path that is simultaneously modified, which was incorrect. * jt/fast-export-copy-modify-fix: fast-export: do not copy from modified file
2017-10-23Merge branch 'nd/worktree-kill-parse-ref' into maintLibravatar Junio C Hamano1-0/+13
"git branch -M a b" while on a branch that is completely unrelated to either branch a or branch b misbehaved when multiple worktree was in use. This has been fixed. * nd/worktree-kill-parse-ref: branch: fix branch renaming not updating HEADs correctly
2017-10-21test-ref-store: avoid passing NULL to printfLibravatar Jeff King1-1/+1
It's possible for resolve_ref_unsafe() to return NULL (e.g., if we are reading and the ref does not exist), in which case we'll pass NULL to printf. On glibc systems this produces "(null)", but on others it may segfault. The tests don't expect any such case, but if we ever did trigger this, we would prefer to cleanly fail the test with unexpected input rather than segfault. Let's manually replace NULL with "(null)". The exact value doesn't matter, as it won't match any possible ref the caller could expect (and anyway, the exit code of the program will tell whether "ref" is valid or not). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-21diff: fix whitespace-skipping with --color-movedLibravatar Jeff King1-0/+67
The code for handling whitespace with --color-moved represents partial strings as a pair of pointers. There are two possible conventions for the end pointer: 1. It points to the byte right after the end of the string. 2. It points to the final byte of the string. But we seem to use both conventions in the code: a. we assign the initial pointers from the NUL-terminated string using (1) b. we eat trailing whitespace by checking the second pointer for isspace(), which needs (2) c. the next_byte() function checks for end-of-string with "if (cp > endp)", which is (2) d. in next_byte() we skip past internal whitespace with "while (cp < end)", which is (1) This creates fewer bugs than you might think, because there are some subtle interactions. Because of (a) and (c), we always return the NUL-terminator from next_byte(). But all of the callers of next_byte() happen to handle that gracefully. Because of the mismatch between (d) and (c), next_byte() could accidentally return a whitespace character right at endp. But because of the interaction of (a) and (b), we fail to actually chomp trailing whitespace, meaning our endp _always_ points to a NUL, canceling out the problem. But that does leave (b) as a real bug: when ignoring whitespace only at the end-of-line, we don't correctly trim it, and fail to match up lines. We can fix the whole thing by moving consistently to one convention. Since convention (1) is idiomatic in our code base, we'll pick that one. The existing "-w" and "-b" tests continue to pass, and a new "--ignore-space-at-eol" shows off the breakage we're fixing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-21t4015: test the output of "diff --color-moved -b"Libravatar Jeff King1-9/+64
Commit fa5ba2c1dd (diff: fix infinite loop with --color-moved --ignore-space-change, 2017-10-12) added a test to make sure that "--color-moved -b" doesn't run forever, but the test in question doesn't actually have any moved lines in it. Let's scrap that test and add a variant of the existing "--color-moved -w" test, but this time we'll check that we find the move with whitespace changes, but not arbitrary whitespace additions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>