# Re: Bug in merge-base 1 messages from 2005-04-19 to 2005-04-19. Participants: Daniel Barkalow. Thread: https://gitlist.dev/t/150 ## Daniel Barkalow, 2005-04-19 23:07 Subject: Re: Bug in merge-base Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.21.0504191853310.30848-100000%40iabervon.org In-Reply-To: <20050419223420.GF9305@pasky.ji.cz> ``` 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 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* ```