Let's start off from where the previous discussion [1] stopped. People
seem to agree ref^{/regex} is a good choice. But we have not come to
conclusion how to specify the count yet. Possible suggestions are
- ref^{/foo}2
- ref^{2/foo}
- ref^{:2/foo}
- ref^{2nd/foo}
For whatever syntax chosen, :/ should benefit too. I notice that :/!
is reserved for future use. Perhaps :/!2/regex is not too cryptic?
I'd also like to do case-insensitive regex, by the way. :/!2i/regex
looks a bit ugly.
[1] http://mid.gmane.org/9D675671-693D-4B59-AF2A-0EFE4C537362@sb.org
Nguyễn Thái Ngọc Duy (2):
get_sha1_oneline: allow to input commit_list
get_sha1: support ref^{/regex} syntax
Documentation/revisions.txt | 7 ++++++
sha1_name.c | 45 ++++++++++++++++++++++++++++++++----------
2 files changed, 41 insertions(+), 11 deletions(-)
--
1.7.3.2.316.gda8b3
This works like :/ syntax, but only limited to one ref.
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
Documentation/revisions.txt | 7 +++++++
sha1_name.c | 26 ++++++++++++++++++++++----
2 files changed, 29 insertions(+), 4 deletions(-)
@@ -106,6 +106,13 @@ the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file. and dereference the tag recursively until a non-tag object is found.+* A suffix '{caret}' to a revision parameter followed by a brace+ pair that contains a text led by a slash (e.g. `HEAD^{/fix nasty bug}`):+ this names a commit whose commit message matches the specified+ regular expression. This name returns the youngest matching commit+ which is reachable from the dereferenced commit. The leading '!'+ in the text is treated especially like in `:/` syntax below.+ * A colon, followed by a slash, followed by a text (e.g. `:/fix nasty bug`): this names a commit whose commit message matches the specified regular expression. This name returns the youngest matching commit which is
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:50:12
Nguyễn Thái Ngọc Duy wrote:
Let's start off from where the previous discussion [1] stopped. People
seem to agree ref^{/regex} is a good choice. But we have not come to
conclusion how to specify the count yet. Possible suggestions are
- ref^{/foo}2
- ref^{2/foo}
- ref^{:2/foo}
- ref^{2nd/foo}
From: Jakub Narebski <hidden> Date: 2016-06-15 22:50:12
On Wed, 8 Dec 2010, Nguyễn Thái Ngọc Duy wrote:
Let's start off from where the previous discussion [1] stopped. People
seem to agree ref^{/regex} is a good choice. But we have not come to
conclusion how to specify the count yet. Possible suggestions are
- ref^{/foo}2
- ref^{2/foo}
- ref^{:2/foo}
- ref^{2nd/foo}
For whatever syntax chosen, :/ should benefit too. I notice that :/!
is reserved for future use. Perhaps :/!2/regex is not too cryptic?
I wonder if it would be possible to make :/<regex> (which looks a bit
like searching the index) to be an alias to --all^{/<regex>}...
Or if we can make ^{/<regex>} to act on revision range specified by
earlier commits, so for example foo..bar^{/<regex>} would work.
I'd also like to do case-insensitive regex, by the way. :/!2i/regex
looks a bit ugly.
The '2nd' idea came from Perl 6 regexp / grammars, see for example
https://github.com/perlpilot/perl6-docs/blob/master/intro/p6-regex-intro.pod
There are two other modifiers for matching a pattern some number of times
or only matching, say, the third time we see a pattern in a string. These
modifiers are a little strange in that their short-hand forms consist of
a number followed by some text:
modifier short-hand meaning
:x() :1x,:4x,:12x match some number of times
:nth() :1st,:2nd,:3rd,:4th match only the Nth occurance
Here are some examples to illustrate these modifiers:
$_ = "foo bar baz blat";
m :3x/ a / # matches the "a" characters in each word
m :nth(3)/ \w+ / # matches "baz"
So it could be e.g. 'foo^{:2nd/<regexp>}' (note that there is no trailing
/ closing regexp, i.e. it is not 'foo^{:2nd/<regexp>/}').
So if we chose this, why don't we follow Perl 6 rule of combining modifiers
http://perlcabal.org/syn/S05.html#Modifiers, so it would be
foo^{:2nd:i/<regexp>}
or
foo^{:i:nth(2)/<regexp>}
As to :/!<regexp> form: isn't it reserved for non-match? If not, then
perhaps
:/!2nd:i/<regexp>
From: Jakub Narebski <hidden> Date: 2016-06-15 22:50:12
Dnia środa 8. grudnia 2010 19:06, Jonathan Nieder napisał:
Nguyễn Thái Ngọc Duy wrote:
quoted
Let's start off from where the previous discussion [1] stopped. People
seem to agree ref^{/regex} is a good choice. But we have not come to
conclusion how to specify the count yet. Possible suggestions are
- ref^{/foo}2
- ref^{2/foo}
- ref^{:2/foo}
- ref^{2nd/foo}
How about
ref^{/foo}^^{/foo}
?
I'll assume that there is invisible ";)" emoticon here.
First, it would be ref^{/foo}^@^{/foo}, otherwise you would follow only
first parent.
Second, consider ref^{:nth(10)/foo} in your workaround...
;-)
--
Jakub Narebski
Poland
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:50:12
Jakub Narebski wrote:
So if we chose this, why don't we follow Perl 6 rule of combining modifiers
http://perlcabal.org/syn/S05.html#Modifiers, so it would be
foo^{:2nd:i/<regexp>}
or
foo^{:i:nth(2)/<regexp>}
@@ -562,6 +563,11 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)expected_type=OBJ_BLOB;elseif(sp[0]=='}')expected_type=OBJ_NONE;+elseif(sp[0]=='/'){+if(sp[1]=='}')+return-1;
Why? $commit^{/} may be a no-op but I do not see a strong reason to
waste extra two lines to forbid it.
quoted hunk
@@ -584,11 +590,23 @@ static int peel_onion(const char *name, int len, unsigned char *sha1) * barf. */ o = peel_to_type(name, len, o, expected_type);- if (o) {- hashcpy(sha1, o->sha1);- return 0;+ if (!o)+ return -1;
I can see you are trying to reduce nesting of
if (o) {
do true thing
return 0
}
return -1;
but then we should apply the same to outer "if (!expected_type) ... else",
too, to unnest the "else" clause by returning from the true branch of that
"if".
I wonder if it would be possible to make :/<regex> (which looks a bit
like searching the index) to be an alias to --all^{/<regex>}...
It looks a bit strange to my eyes to merge normal option name with
revision syntax. But I think it's possible. Do we allow branch/tag
name with leading '-'?
Or if we can make ^{/<regex>} to act on revision range specified by
earlier commits, so for example foo..bar^{/<regex>} would work.
There is another case: branch/tag selection. Instead of looking in all
refs, people may want to look only in nd/* branches. My branches are
almost flat, so I don't find any use. But someone might. And we can
solve the "all branches" case above with simply "*". The exact syntax,
I don't know.
As to :/!<regexp> form: isn't it reserved for non-match?
It is reserved and not attached with any meaning.
Thank you for working on this.
You're welcome. I needed to look for my branches in pu and was tired
of copy/paste.
--
Duy
From: Jakub Narebski <hidden> Date: 2016-06-15 22:50:12
On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:
2010/12/9 Jakub Narebski [off-list ref]:
quoted
I wonder if it would be possible to make :/<regex> (which looks a bit
like searching the index) to be an alias to --all^{/<regex>}...
It looks a bit strange to my eyes to merge normal option name with
revision syntax. But I think it's possible. Do we allow branch/tag
name with leading '-'?
Well, with below proposal it would simply be
--all ^{/<regexp>}
quoted
Or if we can make ^{/<regex>} to act on revision range specified by
earlier commits, so for example foo..bar^{/<regex>} would work.
There is another case: branch/tag selection. Instead of looking in all
refs, people may want to look only in nd/* branches. My branches are
almost flat, so I don't find any use. But someone might. And we can
solve the "all branches" case above with simply "*". The exact syntax,
I don't know.
--glob=heads/nd/ ^{/<regexp>}
Similarly to the --all case.
--
Jakub Narebski
Poland
On Thu, Dec 9, 2010 at 2:51 AM, Jakub Narebski [off-list ref] wrote:
Dnia środa 8. grudnia 2010 19:06, Jonathan Nieder napisał:
quoted
Nguyễn Thái Ngọc Duy wrote:
quoted
Let's start off from where the previous discussion [1] stopped. People
seem to agree ref^{/regex} is a good choice. But we have not come to
conclusion how to specify the count yet. Possible suggestions are
- ref^{/foo}2
- ref^{2/foo}
- ref^{:2/foo}
- ref^{2nd/foo}
How about
ref^{/foo}^^{/foo}
?
I'll assume that there is invisible ";)" emoticon here.
First, it would be ref^{/foo}^@^{/foo}, otherwise you would follow only
first parent.
Second, consider ref^{:nth(10)/foo} in your workaround...
Maybe we should generalize this to apply to all operators. Currently
foo~3 is expanded to foo^^^. How about ~~X (or xN) denote repeat the
last operator N times? For example, HEAD^2x3 => HEAD^2^2^2,
HEAD^{/foo}x3 => HEAD^{/foo}^{/foo}^{/foo}.
--
Duy
On Thu, Dec 9, 2010 at 7:44 AM, Jakub Narebski [off-list ref] wrote:
On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:
quoted
2010/12/9 Jakub Narebski [off-list ref]:
quoted
quoted
I wonder if it would be possible to make :/<regex> (which looks a bit
like searching the index) to be an alias to --all^{/<regex>}...
It looks a bit strange to my eyes to merge normal option name with
revision syntax. But I think it's possible. Do we allow branch/tag
name with leading '-'?
Well, with below proposal it would simply be
--all ^{/<regexp>}
This hardly works with range and may conflict with "--all" being
already used by some commands.
I think we can move '/' out of {}, the space between '/' and '{' can
be used for optional parameters: ^/{foo}.
--
Duy
From: Kevin Ballard <hidden> Date: 2016-06-15 22:50:12
On Dec 8, 2010, at 5:42 PM, Nguyen Thai Ngoc Duy wrote:
On Thu, Dec 9, 2010 at 7:44 AM, Jakub Narebski [off-list ref] wrote:
quoted
On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:
quoted
2010/12/9 Jakub Narebski [off-list ref]:
quoted
quoted
I wonder if it would be possible to make :/<regex> (which looks a bit
like searching the index) to be an alias to --all^{/<regex>}...
It looks a bit strange to my eyes to merge normal option name with
revision syntax. But I think it's possible. Do we allow branch/tag
name with leading '-'?
Well, with below proposal it would simply be
--all ^{/<regexp>}
This hardly works with range and may conflict with "--all" being
already used by some commands.
I think we can move '/' out of {}, the space between '/' and '{' can
be used for optional parameters: ^/{foo}
I thought ^{} was going to be an arbitrary grouping operator, capable of
embedding any other modifier, but primarily only useful for regex. This
change explicitly makes it an alternative regex syntax.
-Kevin Ballard
From: Jakub Narebski <hidden> Date: 2016-06-15 22:50:12
Nguyen Thai Ngoc Duy wrote:
On Thu, Dec 9, 2010 at 2:51 AM, Jakub Narebski [off-list ref] wrote:
quoted
Dnia środa 8. grudnia 2010 19:06, Jonathan Nieder napisał:
quoted
Nguyễn Thái Ngọc Duy wrote:
quoted
Let's start off from where the previous discussion [1] stopped. People
seem to agree ref^{/regex} is a good choice. But we have not come to
conclusion how to specify the count yet. Possible suggestions are
- ref^{/foo}2
- ref^{2/foo}
- ref^{:2/foo}
- ref^{2nd/foo}
How about
ref^{/foo}^^{/foo}
?
I'll assume that there is invisible ";)" emoticon here.
First, it would be ref^{/foo}^@^{/foo}, otherwise you would follow only
first parent.
Second, consider ref^{:nth(10)/foo} in your workaround...
Maybe we should generalize this to apply to all operators. Currently
foo~3 is expanded to foo^^^. How about ~~X (or xN) denote repeat the
last operator N times? For example, HEAD^2x3 => HEAD^2^2^2,
HEAD^{/foo}x3 => HEAD^{/foo}^{/foo}^{/foo}.
Unless you allow grouping, it wouldn't help in the case of ^{/foo},
because ^{/foo} is idempotent. HEAD^{/foo} finds first commit that
contains "foo", and HEAD^{/foo}^{/foo} finds first commit containing
"foo" starting from *and including* first commit from HEAD containing
"foo" - which is HEAD^{/foo}
HEAD^{/foo}^{/foo} === HEAD^{/foo}
You would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2
means really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.
--
Jakub Narebski
Poland
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:50:12
Jakub Narebski wrote:
You would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2
means really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.
That said, does ^2x500 really do something meaningful that a person
would ever need? I like the
^{:nth(3)/foo}
syntax because perl6 supports m:nth(3)/foo/, suggesting a menu of
already-defined modifiers to implement when they prove useful, known
already to a certain subset of the audience and proven useful already
in a different context.
From: Kevin Ballard <hidden> Date: 2016-06-15 22:50:12
On Dec 8, 2010, at 5:59 PM, Jonathan Nieder wrote:
Jakub Narebski wrote:
quoted
You would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2
means really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.
That said, does ^2x500 really do something meaningful that a person
would ever need? I like the
^{:nth(3)/foo}
syntax because perl6 supports m:nth(3)/foo/, suggesting a menu of
already-defined modifiers to implement when they prove useful, known
already to a certain subset of the audience and proven useful already
in a different context.
I like the ^{:nth(3)/foo} syntax as well. Though I'm not familiar with Perl 6,
this does have the benefit of being fairly obvious to the reader as to what it
means.
-Kevin Ballard
On Thu, Dec 9, 2010 at 9:02 AM, Kevin Ballard [off-list ref] wrote:
On Dec 8, 2010, at 5:59 PM, Jonathan Nieder wrote:
quoted
Jakub Narebski wrote:
quoted
You would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2
means really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.
That said, does ^2x500 really do something meaningful that a person
would ever need? I like the
^{:nth(3)/foo}
syntax because perl6 supports m:nth(3)/foo/, suggesting a menu of
already-defined modifiers to implement when they prove useful, known
already to a certain subset of the audience and proven useful already
in a different context.
I like the ^{:nth(3)/foo} syntax as well. Though I'm not familiar with Perl 6,
this does have the benefit of being fairly obvious to the reader as to what it
means.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:50:12
Nguyen Thai Ngoc Duy wrote:
OK so :nth(3)/foo for all branches?
That steals namespace from "the path 'nth(3)/foo' in the index". But
is "the third instance of foo in all branches" something that needs to
be possible to say? Branches do not have a well defined order,
anyway. A command to list all commits with "foo" in the subject
like
git log --oneline --grep-subject=foo
sounds more useful (assuming --grep=foo yields too many false
positives).
From: Jakub Narebski <hidden> Date: 2016-06-15 22:50:12
On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:
On Thu, Dec 9, 2010 at 7:44 AM, Jakub Narebski [off-list ref] wrote:
quoted
On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:
quoted
2010/12/9 Jakub Narebski [off-list ref]:
quoted
quoted
I wonder if it would be possible to make :/<regex> (which looks a bit
like searching the index) to be an alias to --all^{/<regex>}...
It looks a bit strange to my eyes to merge normal option name with
revision syntax. But I think it's possible. Do we allow branch/tag
name with leading '-'?
Well, with below proposal it would simply be
--all ^{/<regexp>}
This hardly works with range and may conflict with "--all" being
already used by some commands.
It is '--all' like in "git log --all".
The proposed semantics for ^{/foo} (i.e. not attached to revision)
would be that it acts on all positive revs on the left of it, replacing
them. But that might be not easy to do, and it feels a bit
overengineered.
I think we can move '/' out of {}, the space between '/' and '{' can
be used for optional parameters: ^/{foo}.
Do you mean using e.g. ^/:i{foo} for :ignorecase, instead of ^{:i/foo}
or ^{i/foo}?
--
Jakub Narebski
Poland
On Thu, Dec 9, 2010 at 6:43 PM, Jakub Narebski [off-list ref] wrote:
On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:
quoted
On Thu, Dec 9, 2010 at 7:44 AM, Jakub Narebski [off-list ref] wrote:
quoted
On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:
quoted
2010/12/9 Jakub Narebski [off-list ref]:
quoted
quoted
I wonder if it would be possible to make :/<regex> (which looks a bit
like searching the index) to be an alias to --all^{/<regex>}...
It looks a bit strange to my eyes to merge normal option name with
revision syntax. But I think it's possible. Do we allow branch/tag
name with leading '-'?
Well, with below proposal it would simply be
--all ^{/<regexp>}
This hardly works with range and may conflict with "--all" being
already used by some commands.
It is '--all' like in "git log --all".
The proposed semantics for ^{/foo} (i.e. not attached to revision)
would be that it acts on all positive revs on the left of it, replacing
them. But that might be not easy to do, and it feels a bit
overengineered.
Yes, maybe.
quoted
I think we can move '/' out of {}, the space between '/' and '{' can
be used for optional parameters: ^/{foo}.
Do you mean using e.g. ^/:i{foo} for :ignorecase, instead of ^{:i/foo}
or ^{i/foo}?
Yes. I find "^/" easier to read than "^{/". But "^{/" is more
consistent to the rest.
--
Duy