On Thu, Jan 3, 2013 at 10:59 AM, Michael Haggerty <mhag...@alum.mit.edu> wrote:
> On 01/03/2013 08:03 AM, Junio C Hamano wrote:
>> I'd like a datastore that maps a pair of commit object names to
>> another object name, such that:
>> * When looking at two commits A and B, efficiently query all data
>> associated with a pair of commits <X,Y> where X is contained in
>> the range A..B and not in B..A, and Y is contained in the range
>> B..A and not in A..B.
>> * When <X,Y> is registered in the datastore, and X is rewritten to
>> X' and/or Y is rewritten to Y', the mapping is updated so that it
>> can be queried with <X',Y'> as a new key, similar to the way a
>> notes tree that maps object X can be updated to map object X'
>> when such a rewrite happens.
>> The intended use case is to "go beyond rerere". Given a history of
>> this shape:
>> o---o---o---I mainline
>> O---o---X---o---A topic A
>> o---Y---o---o---B topic B
I would indeed also be interested in such a feature for my day-to-day
work where we use a workflow similar to git.git's.
> When doing this merge, I think your goal is equivalent to discovering
> that M includes part of the merge of J and B, and adding M as an
> (implicit or explicit) third parent to the merge:
> o---o---o---I---J-------K mainline
> / / . /
> O---o---X---o---A . / topic A
> \ \ . /
> \ M......... /
> \ / /
> o---Y---o---o---B topic B
> 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)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html