All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Rast <trast@inf.ethz.ch>
To: Junio C Hamano <gitster@pobox.com>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	Git List <git@vger.kernel.org>
Subject: Re: [PATCH/RFC] blame: accept multiple -L ranges
Date: Mon, 22 Jul 2013 21:19:17 +0200	[thread overview]
Message-ID: <87bo5uqu6i.fsf@linux-k42r.v.cablecom.net> (raw)
In-Reply-To: <7vr4eqcxub.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Mon, 22 Jul 2013 10:23:56 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>>
>>> The proposal currently is only for "-L /RE/,whatever" to behave in a
>>> relative fashion, beginning the search at the end of the last range
>>> specified via -L (or line 1 if there is no previous -L).
>>>
>>> Would it also make sense to support "-L +N,whatever" as relative to
>>> the end of the last range specified via -L (or 1 if none).
>>
>> Sounds reasonable.
>>
>> I'm still not sure I am super-happy with /RE/ always being relative,
>> though I see Junio's problem space as something worth solving.  How does
>> it interact with -L:RE?  Do you now have to know in what order the
>> functions appear in the source to correctly specify -L:foo -L:bar or
>> similarly, -L/foo/,/^}/ -L/bar/,/^}/?  What if we supported +/RE/ as the
>> relative version?
>
> Two gripes I have are:
>
>  (1) That sounds like making common things more cumbersome to ask.
>
>  (2) In "-L /RE1/,/RE2/", you do not have to say +/RE2/ (and you
>      shouldn't have to).  /RE3/ without any magic that starts
>      searching after the last match in "-L /RE1/,/RE2/ -L /RE3/,+4"
>      feels a lot more consistent than requiring a prefix plus.
>
> I am OK if you made /RE/, which starts searching immediately after
> the last match, wrap around and continue the search at the beginning
> upon finding nothing through the end of the file (and make sure you
> stop if you passed the last match again).  That would solve your "I
> have two functions, and I can give them in any order", while keeping
> the consistency with "In /RE1/,/RE2/, the latter is already relative
> to the former".

Dunno.  It still doesn't really solve the order-of-L problem if there
are multiple matches.

I can't really say how they fare against each other.  I have a bad
feeling about the consistency of what results, but as you say, doing it
the way I suggested isn't very consistent either.  Perhaps in retrospect
even -L/foo/,/bar/ should have required the + in +/bar/ to make it
relative.

I'll just leave it at that and let you decide what to do (presumably go
ahead as you already outlined).  I've never actually ever used multiple
-L in the same log/blame invocation, anyway.  I just think that when it
comes to it, I'll have to read the manpage before I try...

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

  reply	other threads:[~2013-07-22 19:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-07  8:45 [PATCH/RFC] blame: accept multiple -L ranges Eric Sunshine
2013-07-07  9:58 ` Junio C Hamano
2013-07-09 15:04   ` Eric Sunshine
2013-07-09 16:39     ` Junio C Hamano
2013-07-09 17:17       ` Eric Sunshine
2013-07-09 17:42       ` Thomas Rast
2013-07-09 18:23         ` Eric Sunshine
2013-07-09 18:55           ` Junio C Hamano
2013-07-09 19:07             ` Eric Sunshine
2013-07-09 19:12             ` Thomas Rast
2013-07-09 19:21               ` Jonathan Nieder
2013-07-09 19:31               ` Junio C Hamano
2013-07-09 19:57                 ` Michael Haggerty
2013-07-09 20:25                   ` Junio C Hamano
2013-07-22  8:12                     ` Eric Sunshine
2013-07-22 10:39                       ` Thomas Rast
2013-07-22 17:23                         ` Junio C Hamano
2013-07-22 19:19                           ` Thomas Rast [this message]
2013-07-22 21:34                             ` Junio C Hamano
2013-07-10  9:18                 ` Thomas Rast
2013-07-11 16:44                   ` Junio C Hamano
2013-07-09 18:57         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bo5uqu6i.fsf@linux-k42r.v.cablecom.net \
    --to=trast@inf.ethz.ch \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mhagger@alum.mit.edu \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.