Re: git-name-rev off-by-one bug

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 30, 2005, 16:12 UTC
Message-ID: <Pine.LNX.4.64.0511300809300.3099@g5.osdl.org>
In-Reply-To: <20051130060906.13277.qmail@science.horizon.com>

On Tue, 30 Nov 2005, linux@horizon.com wrote:

Show 8 quoted lines

>
> > +-0 -1 -2::
> > +	When an unmerged entry is seen, diff against the base version,
> > +	the "first branch" or the "second branch" respectively.
> > +
> > +	The default is to diff against the first branch.
> 
> Er... why are these flags zero-based?

Because it makes more sense from a "git diff" standpoint to do that.

The fact that _internally_, git puts the first branch into "stage 2", and the second one into "stage 3", that's very much a internal git implementation issue that makes no sense to expose to a regular user.

> git-ls-files -s displays them as "1", "2" and "3".  All the docs talk
> about "stage1", "stage2" and "stage3".

Yes, but those are _technical_ docs, not docs aimed toward a user. Nobody sane uses "git-ls-files --stage" outside of a script, or unless they really know git and are trying to debug something.

>From a user standpoint, it makes a lot more sense to say "primary branch"

and "other branch" , and then "-1" and "-2" make sense (and then the "base of the merge" makes sense as "-0").

		Linus