git/read-tree.c, branch v0.99

git-read-tree: fix "--reset" handling

2005-06-15T17:25:46Z

[PATCH] read-tree: loosen too strict index requirements

2005-06-13T03:40:20Z

This patch teaches read-tree 3-way merge that, when only "the other tree" changed a path, and if the index file already has the same change, we are not in a situation that would clobber the index and the work tree, and lets the merge succeed; this is case #14ALT in t1000 test. It does not change the result of the merge, but prevents it from failing when it does not have to. Signed-off-by: Junio C Hamano Signed-off-by: Linus Torvalds

[PATCH] Finish making --emu23 equivalent to pure 2-way merge.

2005-06-13T03:40:20Z

This adds #3ALT rule (and #2ALT rule for symmetry) to the read-tree 3-way merge logic that collapses paths that are added only in one branch and not in the other internally. This makes --emu23 to succeed in the last remaining case where the pure 2-way merge succeeded and earlier one failed. Running diff between t1001 and t1005 test scripts shows that the only difference between the two is that --emu23 can leave the states into separate stages so that the user can use usual 3-way merge resolution techniques to carry forward the local changes when pure 2-way merge would have refused to run. Signed-off-by: Junio C Hamano Signed-off-by: Linus Torvalds

[PATCH] read-tree: fix too strong index requirement #5ALT

2005-06-13T03:40:20Z

This fixes too strong index requirement 3-way merge enforces in one case: the same file is added in both branches. In this case, the original code insisted that if the index file has that path, it must match our branch and be up-to-date. However in this particular case, it only has to match it, and can be dirty. We just need to make sure that we keep the work-tree copy instead of checking out the merge result. The resolution of such a path, however, cannot be left to outside script, because we will not keep the original stage0 entries for unmerged paths when read-tree finishes, and at that point, the knowledge of "if we resolve it to match the new file added in both branches, the merge succeeds and the work tree would not lose information, but we should _not_ update the work tree from the resulting index file" is lost. For this reason, the now code needs to resolve this case (#5ALT) internally. This affects some existing tests in the test suite, but all in positive ways. In t1000 (3-way test), this #5ALT case now gets one stage0 entry, instead of an identical stage2 and stage3 entry pair, for such a path, and one test that checked for merge failure (because the test assumed the "stricter-than-necessary" behaviour) does not have to fail anymore. In t1005 (emu23 test), two tests that involves a case where the work tree already had a change introduced in the upstream (aka "merged head"), the merge succeeds instead of failing. Signed-off-by: Junio C Hamano Signed-off-by: Linus Torvalds

[PATCH] read-tree --emu23.

2005-06-13T03:40:20Z

This new flag causes two-way fast forward to internally use the three-way merge mechanism. This behaviour is intended to offer a better fast forward semantics when used in a dirty work tree. The new test t1005 is parallel to the existing t1001 "pure 2-way" tests, but some parts that are commented out would fail. These failures are due to three-way merge enforcing too strict index requirements for cases that could succeed. This problem will be addressed by later patches. Without even changing three-way mechanism, the --emu23 two-way fast forward already gives the user an easier-to-handle merge result when a file that "merged head" updates has local modifications. This is demonstrated as "case 16" test in t1005. Signed-off-by: Junio C Hamano Signed-off-by: Linus Torvalds

git-read-tree: remove deleted files in the working directory

2005-06-09T22:34:04Z

Only when "-u" is used of course.

git-read-tree: add "--reset" flag

2005-06-09T19:51:01Z

This is the same as "-m", but it will silently ignore any unmerged entries, which makes it useful for efficiently forcing a new position regardless of the state of the current index file. IOW, to reset to a previous HEAD (in case you have had a failed merge, for example), you'd just do git-read-tree -u --reset HEAD which will also update your working tree to the right state. NOTE! The "update" will not remove files that may have been added by the merge. Yet.

git-read-tree: -u without -m is meaningless. Don't allow it.

2005-06-07T22:20:39Z

Also, documetn the "-u" in the usage string.

git-read-tree: make one-way merge also honor the "update" flag

2005-06-07T22:17:33Z

It didn't set CE_UPDATE before, so "-u" was a no-op.

[PATCH] read-tree: save more user hassles during fast-forward.

2005-06-07T18:41:51Z

This implements the "never lose the current cache information or the work tree state, but favor a successful merge over merge failure" principle in the fast-forward two-tree merge operation. It comes with a set of tests to cover all the cases described in the case matrix found in the new documentation. Signed-off-by: Junio C Hamano Signed-off-by: Linus Torvalds