Re: [PATCH v4 0/4] Add --no-ahead-behind to status
- Date: Tue, 9 Jan 2018 17:48:58 +0100 (STD)
- From: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
- Subject: Re: [PATCH v4 0/4] Add --no-ahead-behind to status
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
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.