git/t, branch v1.0.0

Racy GIT (part #2)

2005-12-20T20:12:18Z

The previous round caught the most trivial case well, but broke down once index file is updated again. Smudge problematic entries (they should be very few if any under normal interactive workflow) before writing a new index file out. Signed-off-by: Junio C Hamano

Racy GIT

2005-12-20T08:22:28Z

This fixes the longstanding "Racy GIT" problem, which was pretty much there from the beginning of time, but was first demonstrated by Pasky in this message on October 24, 2005: http://marc.theaimsgroup.com/?l=git&m=113014629716878 If you run the following sequence of commands: echo frotz >infocom git update-index --add infocom echo xyzzy >infocom so that the second update to file "infocom" does not change st_mtime, what is recorded as the stat information for the cache entry "infocom" exactly matches what is on the filesystem (owner, group, inum, mtime, ctime, mode, length). After this sequence, we incorrectly think "infocom" file still has string "frotz" in it, and get really confused. E.g. git-diff-files would say there is no change, git-update-index --refresh would not even look at the filesystem to correct the situation. Some ways of working around this issue were already suggested by Linus in the same thread on the same day, including waiting until the next second before returning from update-index if a cache entry written out has the current timestamp, but that means we can make at most one commit per second, and given that the e-mail patch workflow used by Linus needs to process at least 5 commits per second, it is not an acceptable solution. Linus notes that git-apply is primarily used to update the index while processing e-mailed patches, which is true, and git-apply's up-to-date check is fooled by the same problem but luckily in the other direction, so it is not really a big issue, but still it is disturbing. The function ce_match_stat() is called to bypass the comparison against filesystem data when the stat data recorded in the cache entry matches what stat() returns from the filesystem. This patch tackles the problem by changing it to actually go to the filesystem data for cache entries that have the same mtime as the index file itself. This works as long as the index file and working tree files are on the filesystems that share the same monotonic clock. Files on network mounted filesystems sometimes get skewed timestamps compared to "date" output, but as long as working tree files' timestamps are skewed the same way as the index file's, this approach still works. The only problematic files are the ones that have the same timestamp as the index file's, because two file updates that sandwitch the index file update must happen within the same second to trigger the problem. Signed-off-by: Junio C Hamano

tests: make scripts executable

2005-12-20T02:27:04Z

just for consistency. Signed-off-by: Junio C Hamano

Revert "get_sha1_basic(): corner case ambiguity fix"

2005-12-18T07:10:56Z

This reverts 6677c4665af2d73f670bec382bc82d0f2e9513fb commit. The misguided disambiguation has been reverted, so there is no point testing that misfeature.

get_sha1_basic(): corner case ambiguity fix

2005-12-15T20:54:00Z

When .git/refs/heads/frotz and .git/refs/tags/frotz existed, and the object name stored in .git/refs/heads/frotz were corrupt, we ended up picking tags/frotz without complaining. Worse yet, if the corrupt .git/refs/heads/frotz was more than 40 bytes and began with hexadecimal characters, it silently overwritten the initial part of the returned result. This commit adds a couple of tests to demonstrate these cases, with a fix. Signed-off-by: Junio C Hamano

git rebase loses author name/email if given bad email address

2005-12-15T01:04:47Z

If GIT_AUTHOR_EMAIL is of a certain form, `git rebase master' will blow away the author name and email when fast-forward merging commits. I have not tracked it down, but here is a testcase that demonstrates the behavior. Signed-off-by: Amos Waterland Acked-by: Michal Ostrowski Signed-off-by: Junio C Hamano

t3200: branch --help does not die anymore.

2005-12-14T10:53:43Z

Signed-off-by: Junio C Hamano

Make git-send-pack exit with error when some refs couldn't be pushed out

2005-12-14T02:15:02Z

In case some refs couldn't be pushed out due to an error (mostly the not-a-proper-subset error), make git-send-pack exit with non-zero status after the push is over (that is, it still tries to push out the rest of the refs). [jc: I adjusted a test for this change.] Signed-off-by: Petr Baudis Signed-off-by: Junio C Hamano

Revert "Add deltifier test."

2005-12-13T00:43:15Z

This reverts e726715a52e25d8035c89d4ea09398599610737e commit, because reverting diff-delta emptiness change would break this test.

Add deltifier test.

2005-12-12T20:57:25Z

This test kicks in only if you built test-delta executable, and makes sure that the basic delta routine is working properly even on empty files. This commit is to make sure we have a test to catch the breakage. The delitifier code is still broken, which will be fixed with the next commit. Signed-off-by: Junio C Hamano