On 04/05/2013 09:36 PM, Antoine Pelisse wrote:
> On Thu, Jan 3, 2013 at 10:59 AM, Michael Haggerty <[email protected]>
> 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
[email protected]
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
