DORMANTno replies

[PATCH 0/5] merge-recursive D/F conflict improvements

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:03

This series is on top of my "read-tree-df" topic, which is in
'next'.

The part that are already in 'next' deal with switching branches
when the current branch has a file (or symlink) where the
switched-to branch has a directory (or vice versa), and is about
fixing "git-read-tree -m -u A B" 2-way merges.

This series deals with both "git-read-tree -m u O A B" 3-way
merges, and "git-merge-recursive".  It comes with tests, but
because these two programs are really central part of everyday
branch growing (the other important part is the revision walking
machinery which is obviously the central part of archaeology), I
would really need help from people who have worked in this area
for extra sets of eyeballs.

[PATCH 1/5]
t1000: fix case table.

	This one is immaterial; while working on 2/5, I wondered
	why threeway_merge() did not handle case #10, and tried
	to fix it by adding a case.  Obviously it broke existing
	tests and I recalled that contrary to the case table
	presented there, we decided that "stays in one side
	while the other side removes" case could be a sign of
	the path being renamed away and let the caller deal with
	it.  So this patch fixes the case table to match the
	design and the code.

[PATCH 2/5]
Treat D/F conflict entry more carefully in unpack-trees.c::threeway_merge()

[PATCH 3/5]
merge-recursive: do not barf on "to be removed" entries.

[PATCH 4/5]
merge-recursive: handle D/F conflict case more carefully.

[PATCH 5/5]
t3030: merge-recursive backend test.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help