From: Elijah Newren Date: Thu, 30 Sep 2010 03:22:24 GMT Subject: Re: What's cooking in git.git (Sep 2010, #07; Wed, 29) Message-ID: In-Reply-To: <7vocbgkrw5.fsf@alter.siamese.dyndns.org> Hi, On Wed, Sep 29, 2010 at 6:16 PM, Junio C Hamano 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 when there is also a conflict of some sort at . can result in not being correctly removed and git being unable to populate /*. * 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