Re: [PATCH v2] specifying ranges: we did not mean to make ".." an empty set
- From
Michael J Gruber <git@drmicha.warpmail.net>
- Date
- May 3, 2011, 06:39 UTC
- Message-ID
- <4DBFA31E.40207@drmicha.warpmail.net>
- In-Reply-To
- <20110502210141.GA15753@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 02.05.2011 23:01:
Show 20 quoted lines
> On Mon, May 02, 2011 at 01:56:51PM -0700, Junio C Hamano wrote: > >> Either end of revision range operator can be omitted to default to HEAD, >> as in "origin.." (what did I do since I forked) or "..origin" (what did >> they do since I forked). But the current parser interprets ".." as an >> empty range "HEAD..HEAD", and worse yet, because ".." does exist on the >> filesystem, we get this annoying output: >> >> $ cd Documentation/howto >> $ git log .. ;# give me recent commits that touch Documentation/ area. >> fatal: ambiguous argument '..': both revision and filename >> Use '--' to separate filenames from revisions >> >> Surely we could say "git log ../" or even "git log -- .." to disambiguate, >> but we shouldn't have to. >> >> Helped-by: Jeff King <peff@peff.net> >> Signed-off-by: Junio C Hamano <gitster@pobox.com> > > Looks good to me.
I'm sorry but I don't like this at all, because:
Show 5 quoted lines
> Doing "..." is still allowed, but will never produce any useful results.
> I don't know if it is worth disallowing it to catch errors. I am tempted
> to say it should be magic for "@{u}...HEAD", but I think just "..." is
> getting unreadably magical. "@{u}...HEAD" is already pretty concise and
> is much more readable.We need to disambiguate any pathspec with "--" which could be a revision parameter. Therefore I find it very unnatural to disambiguate ".." to a pathspec automatically (and have "..." error out). "../" is really simple enough to type.
For "..", we should either catch the error or, better, have ".." default to "@{u}..HEAD" and do the same for "...". Those are used much more often, and this goes with "try to parse as a rev first, then pathspec".
Michael