Re: [PATCH v2 0/8] Fix atomicity and avoid fd exhaustion in ref transactions

[Michael Haggerty <mhagger@alum.mit.edu>]

On 05/11/2015 06:30 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> The following other branches, also from my GitHub repo, might be
>> useful:
>>
>> * 'write-refs-sooner-2.3' -- suggested merge of the change to 'maint'.
>>
>> * 'write-refs-sooner-master' -- suggested merge of the change to
>>   'master'.
>>
>> * 'write-refs-sooner-rebased-2.3' and
>>   'write-refs-sooner-rebased-master' -- rebases of 'write-refs-sooner'
>>   onto 'maint' and 'master' respectively, in case anybody is
>>   interested to see how the individual patches would look if
>>   implemented natively on these branches.
> 
> Thanks, that indeed is very helpful and instructive.
> 
> A mechanical merge of sooner-2.2 to maint trivially gave sooner-2.3,
> so I am happy with that one.
> 
> Even though I manually resolved it and the resulting tree pretty
> much matched with your suggested merge, I am hesitant to record the
> change of sooner-2.3 as a single large merge to master.  I am
> tempted to record this as somewhat a wicked merge, e.g.
> 
>  - apply posted patches on maint-2.2, which is your sooner-2.2;
> 
>  - branch sooner-2.3 from maint, merge sooner-2.2;
> 
>  - branch sooner-master from v2.4.0, apply the patches in your
>    sooner-rebased-master on top, and then merge sooner-2.3, possibly
>    with "-s ours"
> 
> And then sooner-master would record both "if built naturally on 2.4"
> progression, which would explain what was done much better than a
> huge merge of sooner-2.3 into 'master', and "what is to be done on
> older codebase".

This is exactly the kind of case that "rebase with history" [1] was
meant to address. But given that our tooling doesn't support such
complicated histories very well, your plan sounds reasonable.

Michael

[1]
http://softwareswirl.blogspot.de/2009/04/truce-in-merge-vs-rebase-war.html

-- 
Michael Haggerty
mhagger@alum.mit.edu