Re: [PATCH v4 0/4] Add --no-ahead-behind to status

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 9, 2018, 16:48 UTC
Message-ID: <nycvar.QRO.7.76.6.1801091744540.37@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <c19f6469-190a-33e7-20a2-fcb17b8e45d9@gmail.com>

Hi Stolee,

On Tue, 9 Jan 2018, Derrick Stolee wrote:

Show 16 quoted lines

> 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