{"thread":{"id":"23351","subject":"Re: [RFD} Use regex's in :/ revision naming machinery","startedAt":"2010-04-06T07:02:00Z","lastAt":"2010-04-06T07:02:00Z","messageCount":1,"participants":["Yann Dirson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"138718","messageId":"20100406090200.46a7c66b@chalon.bertin.fr","threadId":"23351","inReplyTo":null,"subject":"Re: [RFD} Use regex's in :/ revision naming machinery","fromName":"Yann Dirson","fromEmail":"dirson@bertin.fr","sentAt":"2010-04-06T07:02:00Z","receivedAt":"2010-04-06T07:02:00Z","isPatch":false,"sender":{"key":"dirson@bertin.fr","avatar":null},"body":"Let's step in as a user of the feature :)\n\nI started to use :/ very recently, and found it very convenient for my\nparticular use.  I'm running a script which takes a treeish as\nargument, which I regularly run on a dev branch on which I am editing\nthe commits regularly - that is, the commit message rarely change, but\nthe sha1's do.  Then once I have a working :/ expr, I can just reuse\nthe line from shell history, saving typing.\n\nAlso, for composing the :/ expression, I make use of \"git slog|head\"\n(slog being an alias of mostly \"git log --pretty=oneline\"), which helps\nfiguring out a prefix string that does not require too much\nkeystrokes.  There again, it is a gain compared to grabbing the mouse\nto cut+paste a sha1.\n\nJunio wrote:\n>I also happen to think that the current ':/' is more or less useless\n>because you cannot tell it to start digging from only these branches,\n>and it becomes dice-throwing which commit it would find.\n\nNow what I found really strange, is that the \":\" in :/ would not act as\nit does in the [<treeish>]:<file> syntax.  Allowing to use\n[<treeish>]:/<regexp> would not only make it more useful, but also more\nconsistent with that other syntax.\n\n\n>A related but a larger issue is that I suspect this \"two-dot\" would not\n>work, as the syntax looks for \"Merge branch 'slabh'..\" (two-dot taken\n>literally).\n\nRight there is a problem here - even if it works when you mean \"..\" as\nthe range separator, it makes it hard to specify a \"..\" search pattern.\n\nWhat about using \":/pattern/\" as a syntax instead ?  That would also be\nclose to other familiar stuff - although it would now require quoting\na \"/\" to include it in the search pattern...\n\nAnother issue would be to (de)activate regexp processing (as compared\nto just substring or leading-substring behaviour).  Maybe we could use\nsed-like trailing modifiers for this - eg. if regexp is made the\ndefault, \":/obj.c/f\" would not match \"object\".  This would also give us\nprovision to add classical pattern modifiers like /i, and at 1st sight\nwould still be unambiguous wrt the .. separator.\n\nDoes that make sense ?\n-- \nYann\n"}]}