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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 09, 2018 at 02:15:47PM +0100, Johannes Schindelin wrote:

> > I like this direction a lot. I had hoped we could say "100+ commits
> > ahead",
> 
> How about "100+ commits apart" instead?

Yeah, that is probably more accurate for the general case.

> > but I don't think we can do so accurately without generation numbers.
> 
> Even with generation numbers, it is not possible to say whether two given
> commits reflect diverging branches or have an ancestor-descendant
> relationship (or in graph speak: whether they are comparable).
> 
> It could potentially make it possible to cut off the commit traversal, but
> I do not even see how that would be possible.
> 
> The only thing you could say for sure is that two different commits with
> the same generation number are for sure "uncomparable", i.e. reflect
> diverging branches.

I think sometimes we can say more. E.g., imagine we have two commits, A
and B, with generation numbers N and N+1000. We walk back 100 commits
deep from B and end up at a commit around N+900. We know that there are
at least 100 commits in B that are not in A (the 100 we walked, which we
know cannot be ancestors of A because of their generation numbers).
That's true even if there is no ancestry relationship between the two
commits at all.

But we cannot say in that case how many (if any) commits are in A but
not B. So we can say "100+ commits ahead, unknown behind" (or if the two
generation numbers are reversed, we can say "unknown ahead, 100+ commits
behind).

In the more general case, we could actually walk _past_ generation N,
and end up at N-25 or similar. There we can't say anything intelligent
about the commits with generations <= N. But we could say something like
"there are 75 commits in B that cannot be in A" (note that it's probably
_not_ actually 75; it's however many we walked until we crossed N).

So that was what I was getting at in the earlier mail. We can sometimes
give a partial answer. But I think giving that partial answer is likely
to be more confusing than useful to a user, because there are a lot of
caveats about how much we know for a given situation.

And I think from what you wrote below that you probably agree with that
(that we can make a few claims, but not enough to really be useful).

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux