Will Palmer [off-list ref] writes:
- * For future extension, ':/!' is reserved. If you want to match a message
- * beginning with a '!', you have to repeat the exclamation mark.
+ * For negative-matching, prefix the pattern-part with '!-', like: ':/!-WIP'.
+ *
+ * For a literal '!' character at the beginning of a pattern, you have to repeat
+ * that, like: ':/!!foo'
+ *
+ * For future extension, all other sequences beginning with ':/!' are reserved.
*/
Good.
quoted hunk
diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
index e0fe102..8a5983f 100755
--- a/t/t1511-rev-parse-caret.sh
+++ b/t/t1511-rev-parse-caret.sh
@@ -19,13 +19,17 @@ test_expect_success 'setup' '
echo modified >>a-blob &&
git add -u &&
git commit -m Modified &&
+ git branch modref &&
This probably belongs to the previous step, no?
+test_expect_success 'ref^{/!-}' '
+ test_must_fail git rev-parse master^{/!-}
+'
Hmmmm, we must fail because...? We are looking for something that
does not contain an empty string, which by definition does not
exist.
Funny, but is correct ;-).
+test_expect_success 'ref^{/!-.}' '
+ test_must_fail git rev-parse master^{/!-.}
+'
Likewise. I however wonder if we catch a commit without any message
(which you probably have to craft with either commit-tree or
hash-object), but that falls into the "curiosity" not the
"practicality" category.
+test_expect_success 'ref^{/!-non-existent}' '
+ git rev-parse master >expected &&
+ git rev-parse master^{/!-non-existent} >actual &&
+ test_cmp expected actual
+'
OK.
+test_expect_success 'ref^{/!-Changed}' '
+ git rev-parse expref >expected &&
+ git rev-parse master^{/!-Changed} >actual &&
+ test_cmp expected actual
+'
OK.
+test_expect_success 'ref^{/!-!Exp}' '
+ git rev-parse modref >expected &&
+ git rev-parse expref^{/!-!Exp} >actual &&
+ test_cmp expected actual
+'
OK.
test_done
On Mon, Jun 8, 2015 at 5:39 PM, Junio C Hamano [off-list ref] wrote:
Will Palmer [off-list ref] writes:
quoted
diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
index e0fe102..8a5983f 100755
--- a/t/t1511-rev-parse-caret.sh
+++ b/t/t1511-rev-parse-caret.sh
@@ -19,13 +19,17 @@ test_expect_success 'setup' '
echo modified >>a-blob &&
git add -u &&
git commit -m Modified &&
+ git branch modref &&
This probably belongs to the previous step, no?
As it isn't referenced until the "negative" tests, I didn't bother adding
it in the "verify the way things are" tests. Funny that it was mentioned,
as I *did* originally have it in the first commit, but I moved it to the
commit in which it was first used, so that it would be easier to notice.
quoted
+test_expect_success 'ref^{/!-}' '
+ test_must_fail git rev-parse master^{/!-}
+'
Hmmmm, we must fail because...? We are looking for something that
does not contain an empty string, which by definition does not
exist.
Funny, but is correct ;-).
This is left-over from the original patch's logic, which included a
short-circuit to avoid an empty regex (as per 4322842 "get_sha1: handle
special case $commit^{/}")... which I now realise perhaps should
have been simply rephrased, rather than ommitted entirely.
I feel like adding something like:
8<------------------------------------------------------------------------- a/sha1_name.c
+++ b/sha1_name.c
@@ -737,11 +737,15 @@ static int peel_onion(const char *name, int len,
unsigned char *sha1)
/*
* $commit^{/}. Some regex implementation may reject.
- * We don't need regex anyway. '' pattern always matches.
+ * We don't need regex anyway. '' pattern always matches,
+ * and '!' pattern never matches.
*/
if (sp[1] == '}')
return 0;
+ if (sp[1] == '!' && sp[2] == '-' && sp[3] == '}')
+ return -1;
+
prefix = xstrndup(sp + 1, name + len - 1 - (sp + 1));
commit_list_insert((struct commit *)o, &list);
ret = get_sha1_oneline(prefix, sha1, list);
---------------------------------------------------------------------->8
...would be the wrong place for this short-circuit check, in light of
discussion around extensibility; so, I'll see how it looks moving that
into get_sha1_oneline(...)
quoted
+test_expect_success 'ref^{/!-.}' '
+ test_must_fail git rev-parse master^{/!-.}
+'
Likewise. I however wonder if we catch a commit without any message
(which you probably have to craft with either commit-tree or
hash-object), but that falls into the "curiosity" not the
"practicality" category.
A commit with "no message" should indeed by returned by 'master^{/!-.}',
or at least, that is the intent. This test is only meant to cover the
result of there being "no matching commit", however.
In summary: it looks like I'll be sending another one.
Junio C Hamano <gitster <at> pobox.com> writes:
quoted
echo modified >>a-blob &&
git add -u &&
git commit -m Modified &&
+ git branch modref &&
This probably belongs to the previous step, no?
What did you mean by this comment? I looked at the original patch and at
Will's response to your comment and am not quite sure what was meant.
quoted
+test_expect_success 'ref^{/!-}' '
+ test_must_fail git rev-parse master^{/!-}
+'
I plan on leaving this in.
quoted
+test_expect_success 'ref^{/!-.}' '
+ test_must_fail git rev-parse master^{/!-.}
+'
I plan on leaving this in.
On Friday, January 08, 2016 10:21:48 AM Junio C Hamano wrote:
Stephen Smith [off-list ref] writes:
quoted
Junio C Hamano <gitster <at> pobox.com> writes:
quoted
quoted
echo modified >>a-blob &&
git add -u &&
git commit -m Modified &&
+ git branch modref &&
This probably belongs to the previous step, no?
What did you mean by this comment? I looked at the original patch and at
Will's response to your comment and am not quite sure what was meant.
Notice that the title is [2/2], so there is [1/2], which turns out
to be http://article.gmane.org/gmane.comp.version-control.git/270898
I had that patch but didn't connect it to your comment.
That patch updates the preparatory steps of the test script so that
[2/2] have more commits and refs to work with to perform more tests.
Marking the result of that "Modified" commit so that it can be
referenced later with a short name 'modref' is something that should
have done in [1/2], which added that new invocation of "git commit"
to record that "Modified" commit, not in [2/2] as an afterthought
"Oh I created Modified commit in 1/2 so that I can use it in the
test in 2/2, but I forgot to give it a name, so I am adding a new
invocation of 'git branch' in this step".
Yep makes sense.
quoted
quoted
quoted
+test_expect_success 'ref^{/!-}' '
+ test_must_fail git rev-parse master^{/!-}
+'
I plan on leaving this in.
quoted
quoted
+test_expect_success 'ref^{/!-.}' '
+ test_must_fail git rev-parse master^{/!-.}
+'
I plan on leaving this in.
On Fri, Jan 8, 2016 at 1:04 PM, Stephen Smith [off-list ref] wrote:
quoted
quoted
+test_expect_success 'ref^{/!-}' '
+ test_must_fail git rev-parse master^{/!-}
+'
Shouldn't it be ^{!/... instead of ^{/!... ? People could have a
pattern starting with "!" and /! will change its meaning. On the other
hand, anything else after { is still reserved and can safely be used.
--
Duy