Re: What's new in git.git master branch

From: Junio C Hamano <junkio@cox.net>
Date: Dec 1, 2005, 09:38 UTC
Message-ID: <7vmzjljgwo.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051201085433.GA7866@c165.ib.student.liu.se>

Fredrik Kuivinen <freku045@student.liu.se> writes:

Show 6 quoted lines

> It turns out that this change breaks the directory/file conflict
> handling in git-merge-recursive.
>
>    git-ls-tree -r -z <tree SHA1>
>
> Should we do it that way or should ls-tree be changed?

Ouch. Sorry, I should have been more careful. For this particular one, I think updating merge-recursive is less work, so for now I'd vote for that approach. However, as you might already be aware, I am not convinced that the new behaviour is better than the previous round (there is no question about the implementation quality and the clean-up value the rewrite brings), so we might want to also add the "show tree entry in recursive cases too" option to ls-tree as well. What I am saying is essentially, "why not do both?" ;-).

I was looking at the merge-recursive, and there is another topic I wanted to discuss with you about. Conflicts in renaming merges and index collapsing. The latest merge-one-file leaves index entries uncollapsed when the file content changes cannot be automerged, and I think we would want to match that in merge-recursive. When there is no rename involved it can do the same thing as merge-one-file does -- just leave the index unmerged. Renaming case is different.

Currently, rename result is recorded by using "git-update-index --cacheinfo" to populate the index. This method unfortunately can only create a stage0 entry. We can go two ways. One way is to support "register this mode/sha1 tuple at stageN for path" to update-index. Another would be for merge-recursive to first construct three trees with the final directory structure (i.e. prepare three temporary trees with renames applied) and run read-tree 3-way merge on these temporary trees. I suspect the former is probably of lesser impact. Thoughts?

Also I think I broke the case where base trees need to be merged in 58cce8a8 commit (I changed processEntry not to collapse the index entry when file content changes cannot be automerged, but that change has to be done only for the final merge, and merges between base trees must collapse to be able to write the index file out as a tree).