Hi Stolee, On Tue, 9 Jan 2018, Derrick Stolee wrote:
> On 1/9/2018 8:15 AM, Johannes Schindelin wrote: > > > > On Tue, 9 Jan 2018, Jeff King wrote: > > > > > But I don't think you can approximate both ahead and behind together > > > without finding the actual merge base. > > > > > > But even still, finding small answers quickly and accurately and > > > punting to "really far, I didn't bother to compute it" on the big > > > ones would be an improvement over always punting. > > > > Indeed. The longer I think about it, the more I like the "100+ commits > > apart" idea. > > Again, I strongly suggest we drop this approach because it will be more pain > than it is worth. So what you are saying is if there is a commit graph with *heavy* clock skew, you might overestimate how many commits apart the tips are. I say that this is striking the balance between correctness and usability on the *wrong* side. Sure, it might be wrong if your commit graph suffers heavily from clock skew. In most cases, you still get a pretty darn useful hint where you're at. The alternative would be *not* to show any useful hint in most cases, i.e. when you did not find all merge bases within <N> commits. I would really hate it if Git spent so much time and did not even give me a hint. Totally unsatisfying user experience. Ciao, Johannes
