user/sven/git.git/t, branch v2.26.0-rc2

Merge branch 'en/test-cleanup'

2020-03-16T19:43:30Z

Test fixes. * en/test-cleanup: t6022, t6046: fix flaky files-are-updated checks

Merge branch 'es/outside-repo-errmsg-hints'

2020-03-16T19:43:29Z

An earlier update to show the location of working tree in the error message did not consider the possibility that a git command may be run in a bare repository, which has been corrected. * es/outside-repo-errmsg-hints: prefix_path: show gitdir if worktree unavailable

prefix_path: show gitdir if worktree unavailable

2020-03-15T16:35:46Z

If there is no worktree at present, we can still hint the user about Git's current directory by showing them the absolute path to the Git directory. Even though the Git directory doesn't make it as easy to locate the worktree in question, it can still help a user figure out what's going on while developing a script. This fixes a segmentation fault introduced in e0020b2f ("prefix_path: show gitdir when arg is outside repo", 2020-02-14). Signed-off-by: Emily Shaffer [jc: added minimum tests, with help from Szeder Gábor] Signed-off-by: Junio C Hamano

t6022, t6046: fix flaky files-are-updated checks

2020-03-13T20:06:47Z

Several tests wanted to verify that files were actually modified by a merge, which it would do by checking that the mtime was updated. In order to avoid problems with the merge completing so fast that the mtime at the beginning and end of the operation was the same, these tests would first set the mtime of a file to something "old". This "old" value was usually determined as current system clock minus one second, truncated to the nearest integer. Unfortunately, it appears the system clock and filesystem clock are different and comparing across the two runs into race problems resulting in flaky tests. From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond: date will call the gettimeofday system call which will always return the most accurate time available based on the cached kernel time, adjusted by the CPU cycle time if available to give nanosecond resolution. The timestamps stored in the file system however, are only based on the cached kernel time. ie The time calculated at the last timer interrupt. and from https://apenwarr.ca/log/20181113: Does mtime get set to >= the current time? No, this depends on clock granularity. For example, gettimeofday() can return times in microseconds on my system, but ext4 rounds timestamps down to the previous ~10ms (but not exactly 10ms) increment, with the surprising result that a newly-created file is almost always created in the past: $ python -c " import os, time t0 = time.time() open('testfile', 'w').close() print os.stat('testfile').st_mtime - t0 " -0.00234484672546 So, instead of trying to compare across what are effectively two different clocks, just avoid using the system clock. Any new updates to files have to give an mtime at least as big as what is already in the file, so we could define "old" as one second before the mtime found in the file before the merge starts. But, to avoid problems with leap seconds, ntp updates, filesystems that only provide two second resolution, and other such weirdness, let's just pick an hour before the mtime found in the file before the merge starts. Also, clarify in one test where we check the mtime of different files that it really was intentional. I totally forgot the reasons for that and assumed it was a bug when asked. Reported-by: SZEDER Gábor Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

Merge branch 'en/rebase-backend'

2020-03-12T21:28:01Z

Band-aid fixes for two fallouts from switching the default "rebase" backend. * en/rebase-backend: git-rebase.txt: highlight backend differences with commit rewording sequencer: clear state upon dropping a become-empty commit i18n: unmark a message in rebase.c

sequencer: clear state upon dropping a become-empty commit

2020-03-11T19:11:05Z

In commit e98c4269c8 ("rebase (interactive-backend): fix handling of commits that become empty", 2020-02-15), the merge backend was changed to drop commits that did not start empty but became so after being applied (because their changes were a subset of what was already upstream). This new code path did not need to go through the process of creating a commit, since we were dropping the commit instead. Unfortunately, this also means we bypassed the clearing of the CHERRY_PICK_HEAD and MERGE_MSG files, which if there were no further commits to cherry-pick would mean that the rebase would end but assume there was still an operation in progress. Ensure that we clear such state files when we decide to drop the commit. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

Merge branch 'ds/sparse-add'

2020-03-11T17:58:16Z

Test fix. * ds/sparse-add: t1091: don't grep for `strerror()` string

Merge branch 'hd/show-one-mergetag-fix'

2020-03-09T18:21:21Z

"git show" and others gave an object name in raw format in its error output, which has been corrected to give it in hex. * hd/show-one-mergetag-fix: show_one_mergetag: print non-parent in hex form.

Merge branch 'en/test-cleanup'

2020-03-09T18:21:20Z

Test cleanup. * en/test-cleanup: t6020: new test with interleaved lexicographic ordering of directories t6022, t6046: test expected behavior instead of testing a proxy for it t3035: prefer test_must_fail to bash negation for git commands t6020, t6022, t6035: update merge tests to use test helper functions t602[1236], t6034: modernize test formatting

Merge branch 'en/merge-path-collision'

2020-03-09T18:21:20Z

Handling of conflicting renames in merge-recursive have further been made consistent with how existing codepaths try to mimic what is done to add/add conflicts. * en/merge-path-collision: merge-recursive: apply collision handling unification to recursive case