Le dimanche 27 juillet 2008, Junio C Hamano a écrit :
quoted text
>
> The point of merge_bases_many() is that it allows you to compute a merge
> base between a commit and another commit that does not yet exist which is
> a merge across all others.
>
>                o---o---o---o---C
>               /                 :
>              /   o---o---o---B..(M)
>             /   /                 :
> 	---o---*---o---o---o---A..(X)
>
> Suppose you have commits A, B and C, and you would want to come up with
> an Octopus merge X across these three commits.  Because our low-level
> merge machinery works always on two trees with one common ancestor tree,
> we would first create a tree that is a merge between B and C (which is
> marked as (M) in the picture), and then merge the tree of (M) and A using
> common ancestor between (M) and A.
>
> If we did not have merge_bases_many(), we would actually create (M) as a
> real commit, and compute merge base between A and (M), which is marked as
> "*" in the picture.  The use of merge_bases_many() allows us to run the
> same merge base computation without actually creating commit (M). 
> Instead of computing merge-base between A and (M), you can ask for the
> merge base between A ("the first commit") and B, C ("the other commits")
> to obtain the same answer "*".

Yeah, but what is quite confusing I think is that a merge base seems to be 
defined as "an as good as possible _common_ ancestor" but in this case, the 
result of "git merge-base A B C" is not an ancestor of C (even with --all 
option). So perhaps we need a better definition.

quoted text
> Base between A and B is that "*", and you are correct to say that it is
> an ancestor of the "*" that is output from the command; base between A
> and C is the parent of "*", and again you are correct to say it is
> ancestor of the "*" that is output from the command.
>
> But if we output any other commit between "*" and A from the command, it
> still satisifies your condition.  "The merge base between A and each of
> B, C,... should be an ancestor of what is output".  In order to satisify
> your condition, in the extreme case, we could even output A.  Both the
> merge base between A and B, and the merge base between A and C, would be
> an ancestor of A.
>
> So your description may not be incorrect, but I think it completely
> misses the point of what is being computed.
>
> >  Author
> >  ------
> > diff --git a/builtin-merge-base.c b/builtin-merge-base.c
> > index 1cb2925..f2c9756 100644
> > --- a/builtin-merge-base.c
> > +++ b/builtin-merge-base.c
> > @@ -2,9 +2,11 @@
> >  #include "cache.h"
> >  #include "commit.h"
> >
> > -static int show_merge_base(struct commit *rev1, struct commit *rev2,
> > int show_all) +static int show_merge_base(struct commit *rev1, int
> > prev2_nr, +			   struct commit **prev2, int show_all)
> >  {
> > -	struct commit_list *result = get_merge_bases(rev1, rev2, 0);
> > +	struct commit_list *result = get_merge_bases_many(rev1, prev2_nr,
> > +							  prev2, 0);
>
> This is just style, but if you must break lines somewhere, I'd prefer to
> have prev2_nr and prev2 on the same line, like this:
>
> 	struct commit_list *result = get_merge_bases_many(rev1,
> 							  prev2_nr, prev2, 0);
>
> because they logically belong to each other.  Further, I think this
> 84-column single-line statement is perfectly fine as well in this case:
>
> 	struct commit_list *result = get_merge_bases_many(rev1, prev2_nr, prev2,
> 0);
>
> I would probably do this myself in this case, though:
>
> 	struct commit_list *result;
>
> 	result  = get_merge_bases_many(rev1, prev2_nr, prev2, 0);

I used that in v3.

Thanks,
Christian.



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html