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

From: Elijah Newren <newren@gmail.com>
Date: Sep 30, 2010, 03:22 UTC
Message-ID: <AANLkTikf8DogBmprAxh+VusQvn5e3BOJz41fn+5Uiu9k@mail.gmail.com>
In-Reply-To: <7vocbgkrw5.fsf@alter.siamese.dyndns.org>

Hi,

On Wed, Sep 29, 2010 at 6:16 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

> * 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