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

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Apr 6, 2013, 07:55 UTC
Message-ID: <515FD509.4070307@alum.mit.edu>
In-Reply-To: <CALWbr2xOt-tRy1iPJft28O1-fDVo1=DZhEZX6Me3Mt4pZjMyFw@mail.gmail.com>

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

Show 31 quoted lines

> On Thu, Jan 3, 2013 at 10:59 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> 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/