Re: [PATCH] Introduce get_octopus_merge_bases() in commit.c
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jun 9, 2008, 23:31 UTC
- Message-ID
- <alpine.DEB.1.00.0806100024310.1783@racer>
- In-Reply-To
- <7v8wxefbtn.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 9 Jun 2008, Junio C Hamano wrote:
Show 47 quoted lines
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > +struct commit_list *get_octopus_merge_bases(struct commit_list *in, int cleanup)
> > +{
> > + struct commit_list *ret, *i;
> > +
> > + ret = merge_bases_many(in->item, in->next);
> > + if (cleanup)
> > + for(i = in; i; i = i->next)
> > + clear_commit_marks(i->item, all_flags);
> > + return ret;
> > +}
>
> I suspect either me or you are confused, but how is this exactly used?
>
> The code for merge_bases_many(), at least the one I showed you a few days
> ago, is not a replacement for "show-branch --merge-base", and I do not
> think you would want to use it as such in the rewrite of git-merge, if you
> are trying to replace this part of git-merge.sh:
>
> case "$#" in
> 1)
> common=$(git merge-base --all $head "$@")
> ;;
> *)
> common=$(git show-branch --merge-base $head "$@")
> ;;
> esac
>
> The purpose of merge-base-many code was to improve this line in the
> git-merge-octopus.sh:
>
> common=$(git merge-base --all $MRC $SHA1) ||
> die "Unable to find common commit with $SHA1"
>
> Instead of keeping a single MRC, we can compute the merge-base-many
> between the SHA1 (i.e. the one we are looking at right now -- it is fed as
> "one") and all the previous SHA1's we have already looked at (they become
> "two's"), like this:
>
> common($git merge-base-many $SHA1 $SHA1_SO_FAR)
>
> and you would have at the end of the loop:
>
> SHA1_SO_FAR="$SHA1_SO_FAR$SHA1 "
>
> or something.Ah! Even I thought that merge_bases_many() was meant for the show-branch --merge-base case.
However, your remark about optimizing for the two-head case got me thinking: should we not rather use the simple algorithm Miklos proposed for octopus_merge_bases(), even if it is suboptimal?
Octopus is such a rare case that it is more important to have a robust, working code, than a fast one, right? Especially since Octopus will be exercized much less often, and therefore has a higher chance of hiding a bug.
Ciao, Dscho