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

[Junio C Hamano <junkio@cox.net>]

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

> 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).