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

Re: [PATCH/RFC] blame: accept multiple -L ranges

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 9, 2013, 16:39 UTC
Message-ID
<7v38rnwuvb.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CAPig+cQ9sfV+PRqn5vrL0=xOZrKDDmsKdAPiB4PsCFb=jnk4kQ@mail.gmail.com>
Eric Sunshine <sunshine@sunshineco.com> writes:
Show 7 quoted lines
> As implemented by this patch, the behavior of git-blame with multiple
> -L's is consistent with that of git-log with multiple -L's. The
> implemented behavior feels intuitive to me, but I can see how the
> behavior you suggest could feel intuitive to others.
>
> If I re-do the patch to work the way you describe above, how should we
> deal with the inconsistent behaviors between the two commands?

To be extremely honest, I do not care too deeply about what log -L does today, because it is still in "may have rough edges but is an interesting toy to play with" state in my mind ;-)

The suggestion to error out was more about "start simple, strict and obvious to make it easy to explain" and nothing else. If we start with a simple and strict version, we can later loosen it without making an input that was valid earlier invalid. If we start with too loose, on the other hand, it would be hard to tighten it later.

But the only two things I care deeply about are, in a file whose contents is:

	C
        B
        A
        B
        C
        D
 (1) The range "-L /A/,/B/" finds the first A from the beginning,
     and then chooses B that comes _after_ it, making it equivalent
     to -L3,4 (not -L3,2 or -L2,3).
 (2) In the ranges "-L <anything>,/B/ -L /C/,<anything>", the
     beginning of the second range is found by choosing C that comes
     _after_ the end of the previous range (/B/ may choose either
     the second or the 4th line, and the only C that comes after
     either of them is the 5th line and that is where the second
     range should begin, not at the beginning of the file).  The
     same for "-L 1,3 -L /C/" (only C that comes after 3 is eligible
     to be the beginning of the second range).

I view it as a nice addition to coalesce two overlapping ranges given exactly by numbers, e.g. "-L 100,200 -L 50,102". I do not have a strong objection to it, as long as it does not interfere negatively with ranges specified by patterns.

Thanks.
Previous: Eric SunshineNext: Eric Sunshine
Message 4 of 22 in “blame: accept multiple -L ranges”
  1. blame: accept multiple -L rangesEric Sunshine, Jul 7, 2013
  2. Junio C HamanoJul 7, 2013
  3. Eric SunshineJul 9, 2013
  4. Junio C HamanoJul 9, 2013
  5. Eric SunshineJul 9, 2013
  6. Thomas RastJul 9, 2013
  7. Eric SunshineJul 9, 2013
  8. Junio C HamanoJul 9, 2013
  9. Eric SunshineJul 9, 2013
  10. Thomas RastJul 9, 2013
  11. Jonathan NiederJul 9, 2013
  12. Junio C HamanoJul 9, 2013
  13. Michael HaggertyJul 9, 2013
  14. Junio C HamanoJul 9, 2013
  15. Eric SunshineJul 22, 2013
  16. Thomas RastJul 22, 2013
  17. Junio C HamanoJul 22, 2013
  18. Thomas RastJul 22, 2013
  19. Junio C HamanoJul 22, 2013
  20. Thomas RastJul 10, 2013
  21. Junio C HamanoJul 11, 2013
  22. Junio C HamanoJul 9, 2013

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.