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

Michael Haggerty [off-list ref] 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".

I dunno.

Anyway, these patches looked good both on 2.2 and on 2.4.  Thanks.

On 05/11/2015 06:30 AM, Junio C Hamano wrote:

Michael Haggerty [off-list ref] writes:

quoted

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

On Sun, May 10, 2015 at 11:52 PM, Michael Haggerty [off-list ref] wrote:

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.

As a side note to your blog post unrelated to the current series:

I think the new proposed history for "rebase-by-merging-a-patch-at-a-time" also
improves bisectability because you have less long running side branches
(as compared to both in traditional rebase and traditional merge), but a finer
meshed DAG where it is easier to split the commit range into half its size.
When going back one step in history you have more merge nodes where
bisect can decide how many commits to chop off of the new range.

Michael

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

--
Michael Haggerty
mhagger@alum.mit.edu

On Sun, May 10, 2015 at 9:30 PM, Junio C Hamano [off-list ref] wrote:

Michael Haggerty [off-list ref] writes:

quoted

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

I dunno.

Anyway, these patches looked good both on 2.2 and on 2.4.  Thanks.

The patches from Michael all look good. The one he picked up from me has a
weird commit message, though.

Thanks,
Stefan

On Mon, May 11, 2015 at 7:10 PM, Stefan Beller [off-list ref] wrote:

On Sun, May 10, 2015 at 11:52 PM, Michael Haggerty [off-list ref] wrote:

quoted

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.

As a side note to your blog post unrelated to the current series:

I think the new proposed history for "rebase-by-merging-a-patch-at-a-time" also
improves bisectability because you have less long running side branches
(as compared to both in traditional rebase and traditional merge), but a finer
meshed DAG where it is easier to split the commit range into half its size.
When going back one step in history you have more merge nodes where
bisect can decide how many commits to chop off of the new range.

Yeah, this was discussed at the Git Merge 2013 in Berlin, where
Michael gave two presentations (one on the developer day and one on
the user day) about git-imerge. We also discussed the idea of using a
replace ref to be able to switch between different "views" of the
merge, for example one view where you see only one commit for the
whole merge/rebase with history, and one view where you see all the
micro merge commits.

Best,
Christian.