git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
May 4, 2011, 06:55 UTC
Message-ID
<4DC0F845.2080903@drmicha.warpmail.net>
In-Reply-To
<7vvcxrit07.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 03.05.2011 19:38:
Show 21 quoted lines
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>>>> 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:
>>
>>> 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.
> 
> If you are comfortable typing "../", why do you even care?  It would be a
I care about:
- sane defaults
- sane arguments
Show 11 quoted lines
> different story if the patch made ".." error out and forbade to be used as
> an empty range even when you disambiguated, i.e. "git log .. --", but that
> is not what we are doing.
> 
> And we do not even special case "...".  Between the two potential requests
> of asking for an empty revision range and asking for a pathspec "...", both
> are just as unlikely.
> 
> Contrast that with ".." and realize that is very different.  It is
> infinitely more likely that the user meant the immediate parent directory
> than an empty revision range.

and that is a straw man argument. I suggested "@{u}..HEAD" for "..", because I consider that much more useful. "Infinitely more likely" is obviously true and obviously pointless when you compare with something of zero likelihood (and nonsense otherwise). I have no problem accepting a majority vote or sane arguments, but not something like this, sorry.

Michael
Previous: Junio C HamanoNext: Junio C Hamano
Message 11 of 19 in “[Annoyance] "git log .." thinks ".." is ambiguous”
  1. Junio C HamanoMay 2, 2011
  2. Jeff KingMay 2, 2011
  3. Jeff KingMay 2, 2011
  4. Junio C HamanoMay 2, 2011
  5. Jeff KingMay 2, 2011
  6. specifying ranges: we did not mean to make ".." an empty setJunio C Hamano, May 2, 2011
  7. Jeff KingMay 2, 2011
  8. Junio C HamanoMay 2, 2011
  9. Michael J GruberMay 3, 2011
  10. Junio C HamanoMay 3, 2011
  11. Michael J GruberMay 4, 2011
  12. Junio C HamanoMay 4, 2011
  13. Junio C HamanoMay 4, 2011
  14. Joshua JuranMay 3, 2011
  15. Michael J GruberMay 3, 2011
  16. Joshua JuranMay 3, 2011
  17. Michael J GruberMay 3, 2011
  18. Junio C HamanoMay 3, 2011
  19. John SzakmeisterMay 3, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.