Re: [PATCH 1/2] test for '!' handling in rev-parse's named commits
Will Palmer wmpal...@gmail.com writes:
What I'm thinking now is that @^{/foo} can be thought of as a
potential shorthand-form of what could be @^{/!(m=foo)}, in which
case @^{/!-foo} could similarly be thought of as a potential
shorthand-form of what could be @^{/!(m-foo)}.
Ah, our messages crossed, it seems. Yes, I think we are on the same
page, and it is sensible to think of /!-string as a short-hand for
the more complete syntax that uses descriptive word, not mnemonic,
e.g. /!(unmatch=string), that the old thread envisioned.
I think it is OK (and probably preferrable) to start with only
/!-string without the long-hand, as we do not know how multiple
long-hand instructions should interact with each other.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] test for '!' handling in rev-parse's named commits
On Wed, Jun 3, 2015 at 10:52 PM, Junio C Hamano gits...@pobox.com wrote:
The /! sequence being reserved does not mean it was planned to be
used only for a single thing in the future, though.
(snip)
cf. http://thread.gmane.org/gmane.comp.version-control.git/40460/focus=40477
Thank you for that additional context, which I didn't see previously.
Using /!Message to match commits that do not match Message
directly goes against that extensivility design.
We need to always remind ourselves that our latest shiny new toy
will not be the final new feature. There always will be need to add
yet another new thing, and we need to keep the door open for them.
Perhaps
/!-string - find commit without string
or something?
What I'm thinking now is that @^{/foo} can be thought of as a
potential shorthand-form of what could be @^{/!(m=foo)}, in which
case @^{/!-foo} could similarly be thought of as a potential
shorthand-form of what could be @^{/!(m-foo)}.
So with that in mind, I agree that a syntax of @^{/!-foo} could indeed give
me the results I'm looking for, while leaving room for the previously
mentioned forms of future extension.
I don't know if I consider those potential extensions to be commendable
as a unified (and chain-able) syntax for finding revisions in the graph,
or to be needless clutter which would only add yet another way to specify
the same thing. I mean, I like the idea of being able to specify that
I want The third parent of the first commit authored by Fred which is
also an ancestor of a commit which touched a file in the libraries
subdirectory, it sounds like maybe it would be good to be able to do
that sort of thing without bringing xargs and shell expansion into the
picture... but I certainly don't have a clue what it might be good for!
In any case, it sounds like we have a good way forward for this smaller
change, at least. I'll re-submit with the suggested syntax.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] test for '!' handling in rev-parse's named commits
Junio C Hamano gits...@pobox.com writes: The anticipation is to use another feature introducer after /! to enhance the matching, so that we can keep enhancing the syntax. cf. http://thread.gmane.org/gmane.comp.version-control.git/40460/focus=40477 Using /!Message to match commits that do not match Message directly goes against that extensivility design. We need to always remind ourselves that our latest shiny new toy will not be the final new feature. There always will be need to add yet another new thing, and we need to keep the door open for them. Perhaps /!-string - find commit without string or something? Of course, as I do not think it is something people would do regularly to look for a non-match, I do not necessarily think we need a short-hand /!-string. Perhaps following the long-hand syntax suggested in that old article, it may be sensible to start with something more descriptive like /!(negative)string to look for a commit that does not say string, without the short-hand form. Only after we see that people find the feature useful and find the need to use it frequently (if it ever happens, that is), we can introduce /!-string as a short-hand form as a follow-up patch. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] test for '!' handling in rev-parse's named commits
Will Palmer wmpal...@gmail.com writes:
Specifically, as documented: '^{/!Message}' should fail, as this syntax
is currently reserved; while '^{!!Message}' should search for a commit
whose message contains the string !Message.
The /! sequence being reserved does not mean it was planned to be
used only for a single thing in the future, though.
Think of it as a syntax to introduce extended features, the first
use of which was this:
/!!string - find commit with !string
The above is just one feature that the reserved syntax allows,
namely, to find a string that begins with an exclamation mark.
The anticipation is to use another feature introducer after /! to
enhance the matching, so that we can keep enhancing the syntax.
cf. http://thread.gmane.org/gmane.comp.version-control.git/40460/focus=40477
Using /!Message to match commits that do not match Message
directly goes against that extensivility design.
We need to always remind ourselves that our latest shiny new toy
will not be the final new feature. There always will be need to add
yet another new thing, and we need to keep the door open for them.
Perhaps
/!-string - find commit without string
or something?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
