Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:45:03

Johannes Schindelin [off-list ref] writes:
BTW I seem to recall that get_merge_bases_many() was _not_ the same as 
get_merge_octopus().  Could you please remind me what _many() does?
I explained what merge-bases-many gives in a separate message last night
with pictures.

get_merge_octopus() is a more or less useless function.  It is there only
because the protocol between "merge" and strategies requires that the
former have to pass _some_ bases to the latter.  In fact, the octopus
strategy implementation completely ignores the heads given by "merge";
a single set of merge base given from outside is not even useful when you
build octopus by repeatedly running pairwise three-way merges.

With Christian's git-merge-base enhancement, the big comment at the end of
git-merge-octopus's main loop can go with a much improved "next" merge
base computation.

Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:45:03

Hi,

On Sun, 27 Jul 2008, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
BTW I seem to recall that get_merge_bases_many() was _not_ the same as 
get_merge_octopus().  Could you please remind me what _many() does?
I explained what merge-bases-many gives in a separate message last night 
with pictures.
I missed that, alright.
get_merge_octopus() is a more or less useless function.  It is there 
only because the protocol between "merge" and strategies requires that 
the former have to pass _some_ bases to the latter.
Does it?  I thought that e.g. merge-recursive accepts an empty set of 
merge bases?  AFAIR that was the reason why gitk could be merged so well.
In fact, the octopus strategy implementation completely ignores the 
heads given by "merge"; a single set of merge base given from outside is 
not even useful when you build octopus by repeatedly running pairwise 
three-way merges.

With Christian's git-merge-base enhancement, the big comment at the end 
of git-merge-octopus's main loop can go with a much improved "next" 
merge base computation.
Okay.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help