Re: [PATCH] specifying ranges: we did not mean to make ".." an empty set

From: Jeff King <peff@peff.net>
Date: Aug 23, 2012, 22:14 UTC
Message-ID: <20120823221427.GA9337@sigill.intra.peff.net>
In-Reply-To: <7vhart2sos.fsf@alter.siamese.dyndns.org>

On Thu, Aug 23, 2012 at 02:40:19PM -0700, Junio C Hamano wrote:

Show 14 quoted lines

> > This last sentence confuses me. Now we are documenting that "yes, ..
> > really means HEAD..HEAD, which is the empty range". But isn't the point
> > of this patch to say "sure, it would be the empty range, but because
> > that is stupid and pointless, we do not consider it valid and treat ..
> > as a pathspec"?
> 
> No, we still allow ".." as a short-hand for HEAD..HEAD when it is
> understood as a rev.  We also allow ".." as a pathspec to match the
> parent directory when it is understood as a pathspec.
> 
> The only thing the topic wanted to change was the disambiguation
> logic.  When a string S can name both rev and path, we ask the user
> to disambiguate, but when S is "..", we do not have to (as one
> interpretation is meaningless).

Ah, right. OK, that makes more sense. I wasn't thinking that you could still do:

  git log .. --

if you really wanted to. So yeah, it doesn't belong here...

> I think that documentation belongs to the section of disambiguation
> without "--".  Usually you need to use "--", but ".." is taken as
> path even without "--".

...but I agree it would be worth mentioning there. But I am not sure where "there" is in the current documentation.

Show 9 quoted lines

> An interesting side effect is that
> 
> 	git log .. pu
> 
> used to error out for ".." being both rev and path, but it will
> error out for "pu" not being a path in the working tree.  This is
> because on a command line without "--" disambiguation, once you
> start listing paths, you have to have nothing but paths after that
> point.

Hmm. Yeah, that's a slightly surprising emergent behavior. But I think it is not a big deal since both cases led to errors anyway.

-Peff