On Wed, Jun 3, 2015 at 10:52 PM, Junio C Hamano <gitster@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html