From: Yann Dirson <dirson@bertin.fr>
To: Kevin Ballard <kevin@sb.org>
Cc: git list <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: [RFC] Using gitrevisions :/search style with other operators
Date: Tue, 09 Nov 2010 10:24:28 +0100 [thread overview]
Message-ID: <20101109102428.5ba8dc13@chalon.bertin.fr> (raw)
In-Reply-To: <13A8F1B3-39B0-4D11-8763-9C458F75487D@sb.org>
On Tue, 09 Nov 2010 00:06:47 -0800
Kevin Ballard <kevin@sb.org> wrote:
> On Nov 8, 2010, at 11:30 PM, Yann Dirson wrote:
>
> > Kevin wrote:
> >> Junio wrote:
> >>> $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2'
> > [...]
> >>
> >> Interesting idea. It certainly solves the problem of being able to
> >> embed it within other operations (though you do then have to worry
> >> about escaping any embedded close-parens in the search), though it
> >> does mean my suggestion for being able to select the 2nd (or nth)
> >> match won't work.
> >
> > Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be
> > somewhat consistent with the commit^2 case, and would seem
> > unambiguous as well - a bit weird, though.
>
> This violates the idea that once you reach the end of a ^{} structure,
> it resolves to a commit that can then be modified by subsequent
> operations.
OK, that's kinda related to the "looks weird" issue.
Another idea: origin/pu^{:2/Merge 'kb/blame-author-email'}
Since the foo^{objecttype} syntax would not care for a count, it is not
a problem, and it keeps provision for using a count with future
operators. OTOH, it could be a problem if we extend foo^{bar} to
accept "bar" for other things than object types.
--
Yann Dirson - Bertin Technologies
next prev parent reply other threads:[~2010-11-09 9:35 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-09 7:30 [RFC] Using gitrevisions :/search style with other operators Yann Dirson
2010-11-09 8:06 ` Kevin Ballard
2010-11-09 9:24 ` Yann Dirson [this message]
2010-11-10 0:18 ` Junio C Hamano
2010-11-10 0:33 ` Kevin Ballard
2010-11-10 7:32 ` Yann Dirson
2010-11-10 7:46 ` Kevin Ballard
2010-11-10 7:46 ` Yann Dirson
2010-11-10 15:26 ` Jakub Narebski
2010-11-10 16:37 ` [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax Nguyễn Thái Ngọc Duy
2010-11-10 17:17 ` Matthieu Moy
2010-11-10 17:47 ` Jonathan Nieder
2010-11-11 13:18 ` Nguyen Thai Ngoc Duy
2010-11-10 19:34 ` Junio C Hamano
2010-11-11 1:30 ` Nguyen Thai Ngoc Duy
2010-12-09 21:10 ` Junio C Hamano
2010-12-09 21:37 ` Junio C Hamano
2010-12-10 1:35 ` Nguyen Thai Ngoc Duy
2010-11-10 17:23 ` [RFC] Using gitrevisions :/search style with other operators Junio C Hamano
2010-11-10 18:19 ` Jakub Narebski
2010-11-09 16:10 ` Jeff King
-- strict thread matches above, loose matches on Subject: below --
2010-11-05 22:38 Kevin Ballard
2010-11-08 19:09 ` Junio C Hamano
2010-11-08 22:11 ` Kevin Ballard
2010-11-09 5:16 ` Jeff King
2010-11-09 15:59 ` Junio C Hamano
2010-11-09 16:08 ` Jeff King
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=20101109102428.5ba8dc13@chalon.bertin.fr \
--to=dirson@bertin.fr \
--cc=git@vger.kernel.org \
--cc=kevin@sb.org \
--cc=peff@peff.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).