On Thu, Aug 23, 2012 at 02:40:19PM -0700, Junio C Hamano wrote:
> > 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
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.
> 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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html