{"thread":{"id":"25652","subject":"[RFC] Using gitrevisions :/search style with other operators","startedAt":"2010-11-05T22:38:23Z","lastAt":"2010-11-09T16:08:33Z","messageCount":6,"participants":["Kevin Ballard","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"155270","messageId":"9D675671-693D-4B59-AF2A-0EFE4C537362@sb.org","threadId":"25652","inReplyTo":null,"subject":"[RFC] Using gitrevisions :/search style with other operators","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-11-05T22:38:23Z","receivedAt":"2010-11-05T22:38:23Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"Most of the ways to refer to a git revision can be combined, e.g. I can type\nsomething silly like\n\n  HEAD~2^^2^2~4^{tree}\n\nand this will work as expected.\n\nThere is one operator that doesn't allow this at all, and that's the commit\nmessage search (e.g. :/foo). Every character after the :/ is taken to be\npart of the regular expression. This is rather unfortunate as it prevents me\nfrom doing something like :/foo^ to refer to the parent of the matching commit.\n\nDoes anybody have any opinions on changing this operator? My suggestion would\nbe to treat a second / as a termination of the pattern and allow operators\n(such as ^ or ~<n>) to occur at that point. This would look like\n\n  :/Merge branch 'foo'/^\n\nIf you need a / in your message then you can just escape it with a backslash.\n\nA second change to consider is a syntax to specify that you want the 2nd\n(or nth) match rather than the first. This could be done like\n\n  :/foo/2\n\nunless someone has a better idea.\n\nAnd finally, I'd love to be able to specify the ref to search from. The current\nbehavior is to find the earliest matching commit on any ref, but it seems\nI should be able to type something like\n\n  git merge 'origin/pu:/jh\\/notes-merge/^2'\n\nin order to grab the jh/notes-merge topic branch from origin/pu and merge\nit into HEAD. Currently trying to type something like master:/test will\ntreat /test as a file path on master, which is something that will never\nresolve to a real file due to the leading slash.\n\nComments/suggestions/critiques are welcome.\n\n-Kevin Ballard"},{"id":"155413","messageId":"7vpqufpr7f.fsf@alter.siamese.dyndns.org","threadId":"25652","inReplyTo":"9D675671-693D-4B59-AF2A-0EFE4C537362@sb.org","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-08T19:09:56Z","receivedAt":"2010-11-08T19:09:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Ballard <kevin@sb.org> writes:\n\n> There is one operator that doesn't allow this at all, and that's the commit\n> message search (e.g. :/foo). Every character after the :/ is taken to be\n> part of the regular expression. This is rather unfortunate as it prevents me\n> from doing something like :/foo^ to refer to the parent of the matching commit.\n>\n> Does anybody have any opinions on changing this operator?\n\nIf you mean to change what \":/Merge branch 'kb/blame-author-email'\" means,\nand make my scripts suddenly start breaking, I would be moderately unhappy.\n\nIt is fine if we can enhance the extended SHA-1 vocabulary by introducing\na syntax that used to be illegal, hence there is no chance somebody was\nusing it for other purposes.\n\nI wonder if we can introduce something like ':( ... )' to group things.\nE.g.\n\n    $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2'\n\nI haven't visited the particular codepath for some time, so I don't know\noffhand how involved the change would be, though.\n"},{"id":"155439","messageId":"4F75AA0C-B68A-4ABB-B67A-D7F62D989655@sb.org","threadId":"25652","inReplyTo":"7vpqufpr7f.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-11-08T22:11:54Z","receivedAt":"2010-11-08T22:11:54Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Nov 8, 2010, at 11:09 AM, Junio C Hamano wrote:\n\n> Kevin Ballard <kevin@sb.org> writes:\n> \n>> There is one operator that doesn't allow this at all, and that's the commit\n>> message search (e.g. :/foo). Every character after the :/ is taken to be\n>> part of the regular expression. This is rather unfortunate as it prevents me\n>> from doing something like :/foo^ to refer to the parent of the matching commit.\n>> \n>> Does anybody have any opinions on changing this operator?\n> \n> If you mean to change what \":/Merge branch 'kb/blame-author-email'\" means,\n> and make my scripts suddenly start breaking, I would be moderately unhappy.\n\nAh yes, I suppose you do have a common case it would break.\n\n> It is fine if we can enhance the extended SHA-1 vocabulary by introducing\n> a syntax that used to be illegal, hence there is no chance somebody was\n> using it for other purposes.\n> \n> I wonder if we can introduce something like ':( ... )' to group things.\n> E.g.\n> \n>    $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2'\n> \n> I haven't visited the particular codepath for some time, so I don't know\n> offhand how involved the change would be, though.\n\nInteresting idea. It certainly solves the problem of being able to embed it\nwithin other operations (though you do then have to worry about escaping any\nembedded close-parens in the search), though it does mean my suggestion for\nbeing able to select the 2nd (or nth) match won't work. When I have the time\nI'll start taking a look at the code.\n\nAny comments on my suggestion to specify the ref to search from, e.g.\norigin/pu:/\"Merge 'kb/blame-author-email'\"? As I stated before, I believe\nthis syntax is currently-unused (as it is interpreted as a file lookup, but\nfile paths starting with / will never resolve to anything in testing),\nbut I want to make sure I'm not overlooking something.\n\n-Kevin Ballard"},{"id":"155459","messageId":"20101109051631.GA19867@sigill.intra.peff.net","threadId":"25652","inReplyTo":"4F75AA0C-B68A-4ABB-B67A-D7F62D989655@sb.org","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-11-09T05:16:31Z","receivedAt":"2010-11-09T05:16:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 08, 2010 at 02:11:54PM -0800, Kevin Ballard wrote:\n\n> >    $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2'\n> > \n> > I haven't visited the particular codepath for some time, so I don't know\n> > offhand how involved the change would be, though.\n> \n> Interesting idea. It certainly solves the problem of being able to embed it\n> within other operations (though you do then have to worry about escaping any\n> embedded close-parens in the search), though it does mean my suggestion for\n> being able to select the 2nd (or nth) match won't work. When I have the time\n> I'll start taking a look at the code.\n> \n> Any comments on my suggestion to specify the ref to search from, e.g.\n> origin/pu:/\"Merge 'kb/blame-author-email'\"? As I stated before, I believe\n\nIt seems to me the natural way to do that would be to use our existing\ngeneric \"start at this ref and follow some chain\" syntax, which is\nref^{foo}. For example: origin/pu^{:Merge 'kb/blame-author-email'}.\n\nWe already use it for \"follow tree link\" and \"peel tag objects\", and it\nis syntactically similar to the usual \"follow the ancestry chain\" syntax\n(\"ref^\"). And I believe it should be unambiguous, as nothing that could\ngo in ^{} could start with \":\". And presumably one would have to\nbackslash-escape embedded closing curly braces.\n\nWe also have ref@{upstream}. The analogue here would be\norigin/pu@{:Merge 'kb/blame-author-email'}.\n\nI don't recall whether we put any conscious thought into ref@{upstream}\nversus ref^{upstream}. Certainly the former implies to me finding a\nparticular starting point (as we do for reflogs), and the latter implies\nwalking object graph (either by parent ancestry links, or through\ndereferencing tag and commit pointers). But I may just be rationalizing\nafter the fact. :)\n\nCertainly this particular case seems to me to be more like \"^\" or \"~\";\nyou are walking the ancestry tree not a specific number of steps, but\nuntil you see a particular subject.\n\n-Peff\n"},{"id":"155496","messageId":"7v4obqo5dk.fsf@alter.siamese.dyndns.org","threadId":"25652","inReplyTo":"20101109051631.GA19867@sigill.intra.peff.net","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-09T15:59:03Z","receivedAt":"2010-11-09T15:59:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> Any comments on my suggestion to specify the ref to search from, e.g.\n>> origin/pu:/\"Merge 'kb/blame-author-email'\"? As I stated before, I believe\n>\n> It seems to me the natural way to do that would be to use our existing\n> generic \"start at this ref and follow some chain\" syntax, which is\n> ref^{foo}. For example: origin/pu^{:Merge 'kb/blame-author-email'}.\n>\n> We already use it for \"follow tree link\" and \"peel tag objects\", and it\n> is syntactically similar to the usual \"follow the ancestry chain\" syntax\n> (\"ref^\"). And I believe it should be unambiguous, as nothing that could\n> go in ^{} could start with \":\". And presumably one would have to\n> backslash-escape embedded closing curly braces.\n\nYeah, that may make more sense but I think the operation specifier should\nbe '/', not ':', no?\n\nWe chose ':' as a \"funky SHA-1 expression introducer\" that can be followed\nby other letters to specify what kind of funkiness is being summoned (in\nthe case of ':/string', you are asking for \"search\" funkiness), so that we\ncan extend it with different kind of funkiness later.  That is where my\nearlier ':(...)' came from.\n\n> We also have ref@{upstream}. The analogue here would be\n> origin/pu@{:Merge 'kb/blame-author-email'}.\n>\n> I don't recall whether we put any conscious thought into ref@{upstream}\n> versus ref^{upstream}.\n\nI think that is because it is nonsensical to say sha1@{u} for an arbitrary\nSHA-1 expression (i.e. the operator only makes sense for a branch ref we\ncan find branch.*.merge for).  So from that perspective, you are right\nthat \"Start from this commit and find an ancestor whose log message\ncontains this string\" goes well with \"sha1^{/some string}\"\n"},{"id":"155497","messageId":"20101109160833.GA24975@sigill.intra.peff.net","threadId":"25652","inReplyTo":"7v4obqo5dk.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] Using gitrevisions :/search style with other operators","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-11-09T16:08:33Z","receivedAt":"2010-11-09T16:08:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 09, 2010 at 07:59:03AM -0800, Junio C Hamano wrote:\n\n> > It seems to me the natural way to do that would be to use our existing\n> > generic \"start at this ref and follow some chain\" syntax, which is\n> > ref^{foo}. For example: origin/pu^{:Merge 'kb/blame-author-email'}.\n> \n> Yeah, that may make more sense but I think the operation specifier should\n> be '/', not ':', no?\n\nYeah, I don't know what I was thinking when I wrote the text above. It\nshould definitely be origin/pu^{/Merge...}.\n\n-Peff\n"}]}