Re: [RFD] annnotating a pair of commit objects?

On 04/05/2013 09:36 PM, Antoine Pelisse wrote:

On Thu, Jan 3, 2013 at 10:59 AM, Michael Haggerty [off-list ref] wrote:

quoted

How could M be stored?  Assuming that these type of premerge merges are
sparse, then Jeff's analysis seems good.  Concretely, one could simply
store pointers to M from both X and Y; e.g.,

* Add a note to X with the information "when merging this commit with Y,
use premerge M"

* Add a note to Y with the information "when merging this commit with X,
use premerge M"

Then, when merging, create the set J..B, scan all of the commits on B..J
for these "premerge" notes (O(|B..J|)), and for each one, look in the
set J..B to see if it is present.  The effort should scale like

    O( |J..B| + |B..J| * lg(|J..B|) )

where, of course J and B could be exchanged for either aesthetic or
performance reasons.  (One would also need a mechanism for preventing M
from being garbage-collected.)

I like the idea of using notes and a kind of "pre-merge". The proposal
seems decent to me.

Michael, have you started implementing such a thing ? If you did, I
would love to help as much as I can.
If you didn't, I would like to start implementing this feature (I
think I now have some time to do so).
Maybe that would require some kind of mentoring though. It could be a
nice opportunity for the community to improve that too as a fake
"gsoc" (no google, no summer, no student)

No, I haven't pursued this topic per se.  We don't use such a workflow
on my projects, so it isn't a particular itch of mine.  I am currently
more interested in approaches to merging branches that have diverged
"too far" from each other [1].

There will be some overlap with this idea and my "git-mergemate" project
[2], if I ever find the time to make progress on it.  For that project,
I will also need to store lots of intermediate merge commits, in fact
also merges between parts of two branches.  I had planned to
autogenerate branch names by simply sticking the SHA1s of the parents
together, like maybe

    refs/mergemate/NAME/SHA1-SHA1

or

    refs/mergemate/NAME/SHA1/SHA1

where NAME is the overall name of a merge that is in progress.  These
references would be cleaned up when the merge was complete but would
prevent garbage collection of the intermediate results until then.

I would be happy to collaborate with you but it might not turn out so
well because my time for open-sourcing is so limited and unpredictable.

Michael

[1]
http://softwareswirl.blogspot.de/2012/12/the-conflict-frontier-of-nightmare-merge.html

[2] https://github.com/mhagger/git-mergemate  (yes I know the name sucks)

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/