{"thread":{"id":"53274","subject":"Possible documentation error for \"git revisions\"","startedAt":"2020-04-21T13:49:47Z","lastAt":"2020-04-21T13:49:47Z","messageCount":1,"participants":["Will Palmer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"395832","messageId":"CAAKF_ubf3EMK6sTrvZo1OSVHLiLjnY=S=W7s1CNCkZLSteaa+g@mail.gmail.com","threadId":"53274","inReplyTo":null,"subject":"Possible documentation error for \"git revisions\"","fromName":"Will Palmer","fromEmail":"wmpalmer@gmail.com","sentAt":"2020-04-21T13:49:07Z","receivedAt":"2020-04-21T13:49:47Z","isPatch":false,"sender":{"key":"wmpalmer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/357044?v=4"},"body":"The Documentation/revisions.txt page may have a couple of errors in\nit, regarding \"searching for commits by commit message\"\n\nit states:\n\n':/<text>', e.g. ':/fix nasty bug'::\nA colon, followed by a slash, followed by a text, names\na commit whose commit message matches the specified regular expression.\nThis name returns the youngest matching commit which is\nreachable from any ref, including HEAD.\nThe regular expression can match any part of the\ncommit message. To match messages starting with a string, one can use\ne.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what\nis matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a\nliteral '!' character, followed by 'foo'. Any other sequence beginning with\n':/!' is reserved for now.\nDepending on the given text, the shell's word splitting rules might\nrequire additional quoting.\n\nHowever, I believe that the \":/<text>\" syntax now *always* refers to a\nfile in the tree-object,\nnever a search-by-commit-message. (I wasn't previously aware of this\nchange, but I like it!)\n\nInstead, the syntax \"HEAD^{/<text>}\" *does* appear to perform the\nsearch described by the\ndocumentation for \":/<text>\". This includes the possibility of\nmatching HEAD itself. in my\nown workflow, I've never noticed the distinction, but this does feel\nlike a possible error in code,\nrather than documentation. That said, removing the ability for\n\"HEAD^{/text}\" to match HEAD\nwould potentially leave rev-parse with no method for referring to \"the\nfirst match, even if that\nmatch is HEAD itself\", which I think would be bad to remove.\nPersonally, I always type\nHEAD^{/text} (or HEAD^{/!-text}) when searching for something \"before\"\nHEAD, but I do feel\nthat I would \"expect\" that to match HEAD as well, for what it's worth.\n\nThough fixing this as a matter of documentation would be a very small\nchange, I don't have\ntime right now personally to make it (including necessary steps of\nverification, tracing the\nhistory of when the documentation became out-of-date, ensuring this is\na documentation, not\ncode, issue, etc). So I'm unfortunately probably going to \"fire and\nforget\" this bug report.\n\nThanks to anyone who can complete this!\n\n-- Will Palmer\n"}]}