{"thread":{"id":"150","subject":"Re: Bug in merge-base","startedAt":"2005-04-19T23:07:22Z","lastAt":"2005-04-19T23:07:22Z","messageCount":1,"participants":["Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"900","messageId":"Pine.LNX.4.21.0504191853310.30848-100000@iabervon.org","threadId":"150","inReplyTo":"20050419223420.GF9305@pasky.ji.cz","subject":"Re: Bug in merge-base","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-19T23:07:22Z","receivedAt":"2005-04-19T23:07:22Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 20 Apr 2005, Petr Baudis wrote:\n\n> Dear diary, on Wed, Apr 20, 2005 at 12:17:12AM CEST, I got a letter\n> where Daniel Barkalow <barkalow@iabervon.org> told me that...\n> \n> > I can think of. Are you sure there isn't another path to 5b53d3?\n> \n> I'm not. Actually there well might be.\n> \n> I think merge-base should never take a path which is effectively\n> \"upside-down\" when a straight \"upside\" one is available.\n> \n> Hmm. So what I depended on for merge-base was that when doing it on A\n> and B and A is predecessor of B, then it will always just return A.  I\n> will perhaps need to abuse rev-tree somehow for this then, it looks.\n\nIt is currently optimizing for the shortest longer path, but I guess it\nshould optimize for the shortest shorter path (i.e., the 0-length path\nfrom A to itself always wins).\n\nOn the other hand, the date-based comparison (which you'd get with the\nversion I sent yesterday with [2/4] and [4/4]) would give you the most\nrecent common ancestor, which would necessarily avoid this situation.\n\nDo you want to go with the date-based approach, or should I work out a \nshortest shorter path algorithm?\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"}]}