* Bug in merge-base
@ 2005-04-19 21:31 Petr Baudis
0 siblings, 0 replies; 2+ messages in thread
From: Petr Baudis @ 2005-04-19 21:31 UTC (permalink / raw
To: barkalow; +Cc: git
Hello,
I've hit a strange bug in merge-base I don't want to debug now. ;-)
I've been doing my regular git pull test from my main branch, but
suddenly git merge wanted to do a tree merge instead of fast-forward.
What went wrong?
The commits tree looks like:
36c764 -- 808162 -- ...... -- 8e08e7
5b53d3 -'
(see the rev-tree output at
http://pasky.or.cz/~pasky/dev/git/stuff/rev-tree)
The problem is, merge-base hints me wrong:
$ merge-base 8e08e7 808162
5b53d3
instead of 808162.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Bug in merge-base
[not found] <20050419223420.GF9305@pasky.ji.cz>
@ 2005-04-19 23:07 ` Daniel Barkalow
0 siblings, 0 replies; 2+ messages in thread
From: Daniel Barkalow @ 2005-04-19 23:07 UTC (permalink / raw
To: Petr Baudis; +Cc: git
On Wed, 20 Apr 2005, Petr Baudis wrote:
> Dear diary, on Wed, Apr 20, 2005 at 12:17:12AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
>
> > I can think of. Are you sure there isn't another path to 5b53d3?
>
> I'm not. Actually there well might be.
>
> I think merge-base should never take a path which is effectively
> "upside-down" when a straight "upside" one is available.
>
> Hmm. So what I depended on for merge-base was that when doing it on A
> and B and A is predecessor of B, then it will always just return A. I
> will perhaps need to abuse rev-tree somehow for this then, it looks.
It is currently optimizing for the shortest longer path, but I guess it
should optimize for the shortest shorter path (i.e., the 0-length path
from A to itself always wins).
On the other hand, the date-based comparison (which you'd get with the
version I sent yesterday with [2/4] and [4/4]) would give you the most
recent common ancestor, which would necessarily avoid this situation.
Do you want to go with the date-based approach, or should I work out a
shortest shorter path algorithm?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-04-19 23:03 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20050419223420.GF9305@pasky.ji.cz>
2005-04-19 23:07 ` Bug in merge-base Daniel Barkalow
2005-04-19 21:31 Petr Baudis
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).