Re: What's cooking in git.git (Sep 2010, #07; Wed, 29)

[Elijah Newren <newren@gmail.com>]

Hi,

On Wed, Sep 29, 2010 at 6:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> * en/rename-d-f (2010-09-08) 2 commits
>  - merge-recursive: D/F conflicts where was_a_dir/file -> was_a_dir
>  - t3509: Add rename + D/F conflict testcase that recursive strategy fails
>
> I am not entirely convinced this is a regression free band-aid; need to
> look at this a few more times.

When you rerolled pu after 1.7.3, I noticed this series missing, and
thought I should combine it with my en/merge-recursive series (which
would mean keeping the testcase patch, but the other patch morphs a
bit as it combines with one of the patches from the bigger series).
Now, I'm curious if I should have kept it separate.  Preferences?


Also, although not mentioned in this what's cooking email, I noticed
you also merged en/merge-recursive into pu.  I'll note that there a
couple regression I know of in that series, particularly in handling
of cases with o->call_depth>0.  They're pretty rare so the series
might be safe enough for pu, but I thought you should know they are
there.  In particular,

* Some of the tests break on MacOS X due to it's weird "wc"
* a combined D/F conflict at <path> when there is also a conflict of
some sort at <path>.<ext> can result in <path> not being correctly
removed and git being unable to populate <path>/*.
* Some D/F conflicts combined with criss-cross merges result in a
premature git exit with "BUG: There are unmerged index entries" when
merging merge-bases.

The first two were trivial to fix; I've got them in a reroll I'm
preparing.  The third one, if only interested about regressions
relative to master rather than making sure the merge is performed
correctly, I believe is relatively easy.  But the more general case of
solving all the o->call_depth>0 case is going to be difficult.  I've
started a separate thread about that.

Elijah