{"thread":{"id":"43898","subject":"Extending \"extended SHA1\" syntax to traverse through gitlinks?","startedAt":"2016-08-20T22:50:27Z","lastAt":"2016-08-24T20:22:32Z","messageCount":13,"participants":["Josh Triplett","Jakub Narębski","Junio C Hamano","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"299804","messageId":"20160820225013.l7ynru7hzcmrzff7@x","threadId":"43898","inReplyTo":null,"subject":"Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-08-20T22:50:15Z","receivedAt":"2016-08-20T22:50:27Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"Currently, if you have a branch \"somebranch\" that contains a gitlink\n\"somecommit\", you can write \"somebranch:somecommit\" to refer to the\ncommit, just like a tree or blob.  (\"man git-rev-parse\" defines this\nsyntax in the \"SPECIFYING REVISIONS\" section.)  You can use this\nanywhere you can use a committish, including \"git show\nsomebranch:somecommit\", \"git log somebranch:somecommit..anotherbranch\",\nor even \"git format-patch -1 somebranch:somecommit\".\n\nHowever, you cannot traverse *through* the gitlink to look at files\ninside its own tree, or to look at other commits relative to that\ncommit.  For instance, \"somebranch:somecommit:somefile\" and\n\"somebranch:somecommit~3\" do not work.\n\nI'd love to have a syntax that allows traversing through the gitlink to\nother files or commits.  Ideally, I'd suggest the syntax above, as a\nnatural extension of the existing extended syntax.\n\n(That syntax would potentially introduce ambiguity if you had a file\nnamed \"somecommit:somefile\" or \"somecommit~3\".  That doesn't seem like a\nproblem, though; the existing syntax already doesn't support accessing a\nfile named \"x..y\" or \"x...y\", so scripts already can't expect to access\narbitrary filenames with that syntax without some kind of quoting, wich\nwe also don't have.)\n\nDoes this seem reasonable?  Would a patch introducing such syntax\n(including documentation and tests) be acceptable?\n\n- Josh Triplett\n"},{"id":"299815","messageId":"9bad3d13-3257-2077-a734-f985c375b8d3@gmail.com","threadId":"43898","inReplyTo":"20160820225013.l7ynru7hzcmrzff7@x","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-21T13:46:36Z","receivedAt":"2016-08-21T13:49:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 21.08.2016 o 00:50, Josh Triplett pisze:\n\n> Currently, if you have a branch \"somebranch\" that contains a gitlink\n> \"somecommit\", you can write \"somebranch:somecommit\" to refer to the\n> commit, just like a tree or blob.  (\"man git-rev-parse\" defines this\n> syntax in the \"SPECIFYING REVISIONS\" section.)  You can use this\n> anywhere you can use a committish, including \"git show\n> somebranch:somecommit\", \"git log somebranch:somecommit..anotherbranch\",\n> or even \"git format-patch -1 somebranch:somecommit\".\n> \n> However, you cannot traverse *through* the gitlink to look at files\n> inside its own tree, or to look at other commits relative to that\n> commit.  For instance, \"somebranch:somecommit:somefile\" and\n> \"somebranch:somecommit~3\" do not work.\n\nNote that there is the same problem traversing through trees:\nwhile 'git cat-file -p HEAD:subdir/file' works, the 'HEAD:subdir:file'\ndoesn't:\n\n  $ git cat-file -p HEAD:subdir:file\n  fatal: Not a valid object name HEAD:subdir:file\n\nThough you can do resolve step manually\n\n  $ git cat-file -p $(git rev-parse HEAD:subdir):file\n\nThis works.\n\n> \n> I'd love to have a syntax that allows traversing through the gitlink to\n> other files or commits.  Ideally, I'd suggest the syntax above, as a\n> natural extension of the existing extended syntax.\n\nAnd with the above manual resolving, you can see the problem with\nimplementing it: the git-cat-file (in submodule) and git-rev-parse\n(in supermodule) are across repository boundary.\n\nAlso the problem with proposed syntax is that is not very visible.\nBut perhaps it is all right.  Maybe :/ as separator would be better,\nor using parentheses or braces?\n\n> (That syntax would potentially introduce ambiguity if you had a file\n> named \"somecommit:somefile\" or \"somecommit~3\".  That doesn't seem like a\n> problem, though; the existing syntax already doesn't support accessing a\n> file named \"x..y\" or \"x...y\", so scripts already can't expect to access\n> arbitrary filenames with that syntax without some kind of quoting, which\n> we also don't have.)\n\nErrr... what?\n\n  $ echo A..B >A..B\n  $ git add A..B\n  $ git commit -m 'A..B added'\n  [master 2d69af9] A..B added\n   1 file changed, 1 insertion(+), 1 deletion(-)\n   create mode 100644 A..B\n  $ git show HEAD:A..B\n  A..B\n\n> \n> Does this seem reasonable?  Would a patch introducing such syntax\n> (including documentation and tests) be acceptable?\n\n-- \nJakub Narębski\n\n"},{"id":"299817","messageId":"20160821142634.dorgzldjvc3qiaby@x","threadId":"43898","inReplyTo":"9bad3d13-3257-2077-a734-f985c375b8d3@gmail.com","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-08-21T14:26:54Z","receivedAt":"2016-08-21T14:27:08Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote:\n> W dniu 21.08.2016 o 00:50, Josh Triplett pisze:\n> > Currently, if you have a branch \"somebranch\" that contains a gitlink\n> > \"somecommit\", you can write \"somebranch:somecommit\" to refer to the\n> > commit, just like a tree or blob.  (\"man git-rev-parse\" defines this\n> > syntax in the \"SPECIFYING REVISIONS\" section.)  You can use this\n> > anywhere you can use a committish, including \"git show\n> > somebranch:somecommit\", \"git log somebranch:somecommit..anotherbranch\",\n> > or even \"git format-patch -1 somebranch:somecommit\".\n> > \n> > However, you cannot traverse *through* the gitlink to look at files\n> > inside its own tree, or to look at other commits relative to that\n> > commit.  For instance, \"somebranch:somecommit:somefile\" and\n> > \"somebranch:somecommit~3\" do not work.\n> \n> Note that there is the same problem traversing through trees:\n> while 'git cat-file -p HEAD:subdir/file' works, the 'HEAD:subdir:file'\n> doesn't:\n> \n>   $ git cat-file -p HEAD:subdir:file\n>   fatal: Not a valid object name HEAD:subdir:file\n\nInteresting point; if extending this syntax anyway, any treeish ought to\nwork, not just a committish.\n\n> Though you can do resolve step manually\n> \n>   $ git cat-file -p $(git rev-parse HEAD:subdir):file\n> \n> This works.\n\nTrue, but that seems quite inconvenient.\n\n> > I'd love to have a syntax that allows traversing through the gitlink to\n> > other files or commits.  Ideally, I'd suggest the syntax above, as a\n> > natural extension of the existing extended syntax.\n> \n> And with the above manual resolving, you can see the problem with\n> implementing it: the git-cat-file (in submodule) and git-rev-parse\n> (in supermodule) are across repository boundary.\n\nOnly if the gitlink points to a commit that doesn't exist in the same\nrepository.  A gitlink can point to a commit you already have.\n\n> Also the problem with proposed syntax is that is not very visible.\n> But perhaps it is all right.  Maybe :/ as separator would be better,\n> or using parentheses or braces?\n\nIt seems as visible as the standard commit:path syntax; the second colon\nseems just as visible as the first.  :/ already has a different meaning\n(text search), so that would introduce inconsistency.\n\n> > (That syntax would potentially introduce ambiguity if you had a file\n> > named \"somecommit:somefile\" or \"somecommit~3\".  That doesn't seem like a\n> > problem, though; the existing syntax already doesn't support accessing a\n> > file named \"x..y\" or \"x...y\", so scripts already can't expect to access\n> > arbitrary filenames with that syntax without some kind of quoting, which\n> > we also don't have.)\n> \n> Errr... what?\n> \n>   $ echo A..B >A..B\n>   $ git add A..B\n>   $ git commit -m 'A..B added'\n>   [master 2d69af9] A..B added\n>    1 file changed, 1 insertion(+), 1 deletion(-)\n>    create mode 100644 A..B\n>   $ git show HEAD:A..B\n>   A..B\n\nI stand corrected; I didn't find that.  I thought rev parsing worked\nindependently from the repository, and didn't have any automagic\ndetection based on the contents of the repository?\n\nThis seems ambiguous, and (AFAICT) not documented.  If HEAD:A and B both\nrefer to a commit, in addition to the blob A..B, which will HEAD:A..B\nrefer to?  I did test the HEAD:gitlink..anotherbranch case, and it does\nparse as a range.\n"},{"id":"299859","messageId":"ab6e29c1-ea6d-c1c5-e69f-867c16cc736a@gmail.com","threadId":"43898","inReplyTo":"20160821142634.dorgzldjvc3qiaby@x","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-22T18:39:19Z","receivedAt":"2016-08-22T18:39:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 21.08.2016 o 16:26, Josh Triplett pisze:\n> On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote:\n>> W dniu 21.08.2016 o 00:50, Josh Triplett pisze:\n>>> Currently, if you have a branch \"somebranch\" that contains a gitlink\n>>> \"somecommit\", you can write \"somebranch:somecommit\" to refer to the\n>>> commit, just like a tree or blob.  (\"man git-rev-parse\" defines this\n>>> syntax in the \"SPECIFYING REVISIONS\" section.)  You can use this\n>>> anywhere you can use a committish, including \"git show\n>>> somebranch:somecommit\", \"git log somebranch:somecommit..anotherbranch\",\n>>> or even \"git format-patch -1 somebranch:somecommit\".\n>>>\n>>> However, you cannot traverse *through* the gitlink to look at files\n>>> inside its own tree, or to look at other commits relative to that\n>>> commit.  For instance, \"somebranch:somecommit:somefile\" and\n>>> \"somebranch:somecommit~3\" do not work.\n>>\n>> Note that there is the same problem traversing through trees:\n>> while 'git cat-file -p HEAD:subdir/file' works, the 'HEAD:subdir:file'\n>> doesn't:\n>>\n>>   $ git cat-file -p HEAD:subdir:file\n>>   fatal: Not a valid object name HEAD:subdir:file\n> \n> Interesting point; if extending this syntax anyway, any treeish ought to\n> work, not just a committish.\n\nActually, because you can use simply \"HEAD:subdir/file\" I'd rather\nit didn't work (no two ways of access), unless we can get it for free.\n\n>> Though you can do resolve step manually\n>>\n>>   $ git cat-file -p $(git rev-parse HEAD:subdir):file\n>>\n>> This works.\n> \n> True, but that seems quite inconvenient.\n\nEspecially that for submodules you need:\n\n$ git --git-dir=subdir/.git cat-file -p $(git rev-parse HEAD:subdir):file\n\n(or something like that), assuming that you start in supermodule.\n \n>>> I'd love to have a syntax that allows traversing through the gitlink to\n>>> other files or commits.  Ideally, I'd suggest the syntax above, as a\n>>> natural extension of the existing extended syntax.\n>>\n>> And with the above manual resolving, you can see the problem with\n>> implementing it: the git-cat-file (in submodule) and git-rev-parse\n>> (in supermodule) are across repository boundary.\n> \n> Only if the gitlink points to a commit that doesn't exist in the same\n> repository.  A gitlink can point to a commit you already have.\n\nThe idea of submodules is that tree object in superproject includes\nlink to commit of subproject (so called gitlink).  Tree object is\nin superproject repository, while gitlinked commit is in submodule\nrepository.\n\nTrue, with modern Git the submodule repository is embedded in .git\narea of superproject, with '.git' in submodule being gitling file,\nbut by design those objects are in different repositories, in different\nobject databases.\n\n>> Also the problem with proposed syntax is that is not very visible.\n>> But perhaps it is all right.  Maybe :/ as separator would be better,\n>> or using parentheses or braces?\n> \n> It seems as visible as the standard commit:path syntax; the second colon\n> seems just as visible as the first.  :/ already has a different meaning\n> (text search), so that would introduce inconsistency.\n\nActually \":/\" has a special meaning only if it is at beginning:\n - :/<text> for first matching commit from any ref\n - :/       is 'top directory' pathspec (equivalent to ':(top)')\n\nBut perhaps '//' would be better.\n\n>>> (That syntax would potentially introduce ambiguity if you had a file\n>>> named \"somecommit:somefile\" or \"somecommit~3\".  That doesn't seem like a\n>>> problem, though; the existing syntax already doesn't support accessing a\n>>> file named \"x..y\" or \"x...y\", so scripts already can't expect to access\n>>> arbitrary filenames with that syntax without some kind of quoting, which\n>>> we also don't have.)\n>>\n>> Errr... what?\n>>\n>>   $ echo A..B >A..B\n>>   $ git add A..B\n>>   $ git commit -m 'A..B added'\n>>   [master 2d69af9] A..B added\n>>    1 file changed, 1 insertion(+), 1 deletion(-)\n>>    create mode 100644 A..B\n>>   $ git show HEAD:A..B\n>>   A..B\n> \n> I stand corrected; I didn't find that.  I thought rev parsing worked\n> independently from the repository, and didn't have any automagic\n> detection based on the contents of the repository?\n\nIt probably depends on whether command expects range (like git-log),\nsupports range-like notation (like git-diff), or expects single or\nmultiple things (like git-show).\n\n> This seems ambiguous, and (AFAICT) not documented.  If HEAD:A and B both\n> refer to a commit, in addition to the blob A..B, which will HEAD:A..B\n> refer to?  I did test the HEAD:gitlink..anotherbranch case, and it does\n> parse as a range.\n\nWell, it is ambiguous.\n\nWe would probably want to support some kind of quoting, for example\nHEAD:\"A..B\" (where everything inside \"...\" is c-quoted, but can use utf-8).\n\n-- \nJakub Narębski \n\n\n \n\n"},{"id":"299897","messageId":"20160823065359.34cirqig56fugnwy@x","threadId":"43898","inReplyTo":"ab6e29c1-ea6d-c1c5-e69f-867c16cc736a@gmail.com","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-08-23T06:53:59Z","receivedAt":"2016-08-23T06:56:35Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Mon, Aug 22, 2016 at 08:39:19PM +0200, Jakub Narębski wrote:\n> W dniu 21.08.2016 o 16:26, Josh Triplett pisze:\n> > On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote:\n> >> W dniu 21.08.2016 o 00:50, Josh Triplett pisze:\n> >>> Currently, if you have a branch \"somebranch\" that contains a gitlink\n> >>> \"somecommit\", you can write \"somebranch:somecommit\" to refer to the\n> >>> commit, just like a tree or blob.  (\"man git-rev-parse\" defines this\n> >>> syntax in the \"SPECIFYING REVISIONS\" section.)  You can use this\n> >>> anywhere you can use a committish, including \"git show\n> >>> somebranch:somecommit\", \"git log somebranch:somecommit..anotherbranch\",\n> >>> or even \"git format-patch -1 somebranch:somecommit\".\n> >>>\n> >>> However, you cannot traverse *through* the gitlink to look at files\n> >>> inside its own tree, or to look at other commits relative to that\n> >>> commit.  For instance, \"somebranch:somecommit:somefile\" and\n> >>> \"somebranch:somecommit~3\" do not work.\n> >>\n> >> Note that there is the same problem traversing through trees:\n> >> while 'git cat-file -p HEAD:subdir/file' works, the 'HEAD:subdir:file'\n> >> doesn't:\n> >>\n> >>   $ git cat-file -p HEAD:subdir:file\n> >>   fatal: Not a valid object name HEAD:subdir:file\n> > \n> > Interesting point; if extending this syntax anyway, any treeish ought to\n> > work, not just a committish.\n> \n> Actually, because you can use simply \"HEAD:subdir/file\" I'd rather\n> it didn't work (no two ways of access), unless we can get it for free.\n\nAgreed.  I suspect we'd get it for free if we introduced a syntax for\ntraversing through commits (by allowing that syntax to work with any\ntreeish), but if not, I certainly don't see any value in adding a second\nsyntax for accessing tree contents.\n\n> >>> I'd love to have a syntax that allows traversing through the gitlink to\n> >>> other files or commits.  Ideally, I'd suggest the syntax above, as a\n> >>> natural extension of the existing extended syntax.\n> >>\n> >> And with the above manual resolving, you can see the problem with\n> >> implementing it: the git-cat-file (in submodule) and git-rev-parse\n> >> (in supermodule) are across repository boundary.\n> > \n> > Only if the gitlink points to a commit that doesn't exist in the same\n> > repository.  A gitlink can point to a commit you already have.\n> \n> The idea of submodules is that tree object in superproject includes\n> link to commit of subproject (so called gitlink).  Tree object is\n> in superproject repository, while gitlinked commit is in submodule\n> repository.\n> \n> True, with modern Git the submodule repository is embedded in .git\n> area of superproject, with '.git' in submodule being gitling file,\n> but by design those objects are in different repositories, in different\n> object databases.\n\ngit-submodule handles them that way by default, yes.  But a gitlink\ndoesn't inherently have to point to a separate repository, and even a\nsubmodule could point to an object available in the same repository\n(perhaps via another ref).\n\ngit-series creates such gitlinks, for instance.\n\n> >> Also the problem with proposed syntax is that is not very visible.\n> >> But perhaps it is all right.  Maybe :/ as separator would be better,\n> >> or using parentheses or braces?\n> > \n> > It seems as visible as the standard commit:path syntax; the second colon\n> > seems just as visible as the first.  :/ already has a different meaning\n> > (text search), so that would introduce inconsistency.\n> \n> Actually \":/\" has a special meaning only if it is at beginning:\n\nTrue, but it seems inconsistent to have :/ mean search if at the\nbeginning, or traversal if not.\n\n> But perhaps '//' would be better.\n\nThat does seem unambiguous, and it can't conflict with an existing file.\nDoes it seem reasonable to allow that for the initial commit as well\n('committish//file', as well as 'commit//gitlink//file')?\n\nAlso, while that handles traversal into the tree contained in the\ngitlinked commit, what about navigating by commit (using '~' and '^',\nfor instance)?  Does it seem reasonable to allow those as well, perhaps\nonly if you use // to reach the gitlink?  For instance,\n'commit//gitlink~3', or 'commit//gitlink^{tree}'?\n"},{"id":"299959","messageId":"xmqqy43nwibj.fsf@gitster.mtv.corp.google.com","threadId":"43898","inReplyTo":"ab6e29c1-ea6d-c1c5-e69f-867c16cc736a@gmail.com","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-23T16:39:28Z","receivedAt":"2016-08-23T16:39:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narębski <jnareb@gmail.com> writes:\n\n> Especially that for submodules you need:\n>\n> $ git --git-dir=subdir/.git cat-file -p $(git rev-parse HEAD:subdir):file\n>\n> (or something like that), assuming that you start in supermodule.\n>   ...\n>\n> But perhaps '//' would be better.\n\nIf the users have to know where they need to use different\nseparator, I do not think it is worth complicating the plumbing to\ndo this for them.  I'd rather keep things simple, and let the users\nbuild complex stuff on top of the plumbing.\n"},{"id":"299983","messageId":"b2f7ff11-23b4-1065-2207-43f736c91988@gmail.com","threadId":"43898","inReplyTo":"20160823065359.34cirqig56fugnwy@x","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-23T20:24:53Z","receivedAt":"2016-08-23T20:25:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 23.08.2016 o 08:53, Josh Triplett pisze:\n> On Mon, Aug 22, 2016 at 08:39:19PM +0200, Jakub Narębski wrote:\n>> W dniu 21.08.2016 o 16:26, Josh Triplett pisze:\n>>> On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote:\n>>>> W dniu 21.08.2016 o 00:50, Josh Triplett pisze:\n>>>>>\n[...]\n>>>> And with the above manual resolving, you can see the problem with\n>>>> implementing it: the git-cat-file (in submodule) and git-rev-parse\n>>>> (in supermodule) are across repository boundary.\n>>>\n>>> Only if the gitlink points to a commit that doesn't exist in the same\n>>> repository.  A gitlink can point to a commit you already have.\n>>\n>> The idea of submodules is that tree object in superproject includes\n>> link to commit of subproject (so called gitlink).  Tree object is\n>> in superproject repository, while gitlinked commit is in submodule\n>> repository.\n>>\n>> True, with modern Git the submodule repository is embedded in .git\n>> area of superproject, with '.git' in submodule being gitling file,\n>> but by design those objects are in different repositories, in different\n>> object databases.\n> \n> git-submodule handles them that way by default, yes.  But a gitlink\n> doesn't inherently have to point to a separate repository, and even a\n> submodule could point to an object available in the same repository\n> (perhaps via another ref).\n> \n> git-series creates such gitlinks, for instance.\n\nThe point is that submodule has it's own object database.  It might\nbe the same as superproject's, but you need to handle submodule objects\nbeing in separate submodule repository anyway.  Common repository is\njust a special case.\n\nBy the way, this also means that proposed \"extended extended SHA1\"\nsyntax would be useful to user's of submodules...\n\n>>>> Also the problem with proposed syntax is that is not very visible.\n>>>> But perhaps it is all right.  Maybe :/ as separator would be better,\n>>>> or using parentheses or braces?\n>>>\n>>> It seems as visible as the standard commit:path syntax; the second colon\n>>> seems just as visible as the first.  :/ already has a different meaning\n>>> (text search), so that would introduce inconsistency.\n>>\n>> Actually \":/\" has a special meaning only if it is at beginning:\n> \n> True, but it seems inconsistent to have :/ mean search if at the\n> beginning, or traversal if not.\n\nRight.  It would also mean that if we have directory or submodule\ncalled 'foo:', then 'foo:/bar' would be ambiguous where it was not\nbefore.\n\nBTW. currently there is not much need for quoting, at least not for\nthe ':' as separator.  Files with ':' in them, even if they are\nnamed 'HEAD:foo' can be distinguished with ./HEAD:foo, or with\n':(top)HEAD:foo'.  This would not be the case if supermodule to\nsubmodule separator was ':'; the '//' is safe-ish.\n\nAlso, '//' would have additional meaning, in that left hand side\nand right hand side are in [possibly] different repositories.\n\n\nSidenote (on MS Windows):\n samsung@notebook MINGW64 ~/test (master)\n $ echo 'HEAD:A..B' >'HEAD:A..B'\n\n samsung@notebook MINGW64 ~/test (master)\n $ git add 'HEAD:A..B'\n fatal: pathspec 'HEAD:A..B' did not match any files\n\n samsung@notebook MINGW64 ~/test (master)\n $ ls\n A  A..B  B  HEAD:A..B  file  sub/  subm/\n\n\n>> But perhaps '//' would be better.\n> \n> That does seem unambiguous, and it can't conflict with an existing file.\n> Does it seem reasonable to allow that for the initial commit as well\n> ('committish//file', as well as 'commit//gitlink//file')?\n\nI don't think we can change this without breaking scripts (because it\nwould be breaking backward compatibility).  And adding new syntax...\n\nThe problem might be shells sanitizing input, that is turning '//'\ninto '/' before passing it to command; I don't know if it is a problem.\nProbably not.\n\n> Also, while that handles traversal into the tree contained in the\n> gitlinked commit, what about navigating by commit (using '~' and '^',\n> for instance)?  Does it seem reasonable to allow those as well, perhaps\n> only if you use // to reach the gitlink?  For instance,\n> 'commit//gitlink~3', or 'commit//gitlink^{tree}'?\n\nI don't know which of those work, and which do not:\n\n  HEAD:path/to/submodule~3\n  :0:path/to/submodule^{tree}\n  HEAD~3:path/to/submodule\n\nBut I think the following should work:\n\n  v1.0.1~2^2~4:path/to/submodule~3//inner/subm~4//sub/file\n\n\nNOTE that the syntax allows to start at revision, at the index state\nof superproject, but it only goes to state recorder, or to be recorded\nin the superproject.  There is no syntax to find out HEAD or index\nversion of submodule, unless you are within submodule, isn't it?\n\nBest,\n-- \nJakub Narębski\n\n"},{"id":"300021","messageId":"xmqq60qqu3rl.fsf@gitster.mtv.corp.google.com","threadId":"43898","inReplyTo":"b2f7ff11-23b4-1065-2207-43f736c91988@gmail.com","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-24T05:36:46Z","receivedAt":"2016-08-24T05:44:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narębski <jnareb@gmail.com> writes:\n\n> The point is that submodule has it's own object database.  It might\n> be the same as superproject's, but you need to handle submodule objects\n> being in separate submodule repository anyway.  Common repository is\n> just a special case.\n>\n> By the way, this also means that proposed \"extended extended SHA1\"\n> syntax would be useful to user's of submodules...\n\nNot really.\n\nI think that you gave a prime example why <treeish>:<path1>//<path2>\nis not a useful thing for submodules.  When the syntax resolves to a\n40-hex object name, that object name by itself is not useful.\n\nYou also need to carry an additional piece of information that lets\nyou identify the location of the repository, in which the object\nname is valid, in the current user's context (i.e. somewhere in the\nsuperproject where the submodule lives).  In other words, you'd need\nto carry <treeish>:<path1> around anyway for the object name to be\nuseful, so there is no good reason why anybody should insist that\nthe plumbing level resolve <treeish>:<path1>//<path2> directly to an\nobject name in the first place.\n"},{"id":"300048","messageId":"b264e17a-12ff-69ca-f130-78d2635a0f85@gmail.com","threadId":"43898","inReplyTo":"xmqq60qqu3rl.fsf@gitster.mtv.corp.google.com","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-24T13:16:56Z","receivedAt":"2016-08-24T13:17:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 24.08.2016 o 07:36, Junio C Hamano pisze:\n> Jakub Narębski <jnareb@gmail.com> writes:\n> \n>> The point is that submodule has it's own object database.  It might\n>> be the same as superproject's, but you need to handle submodule objects\n>> being in separate submodule repository anyway.  Common repository is\n>> just a special case.\n>>\n>> By the way, this also means that proposed \"extended extended SHA1\"\n>> syntax would be useful to user's of submodules...\n> \n> Not really.\n> \n> I think that you gave a prime example why <treeish>:<path1>//<path2>\n> is not a useful thing for submodules.  When the syntax resolves to a\n> 40-hex object name, that object name by itself is not useful.\n> \n> You also need to carry an additional piece of information that lets\n> you identify the location of the repository, in which the object\n> name is valid, in the current user's context (i.e. somewhere in the\n> superproject where the submodule lives).  In other words, you'd need\n> to carry <treeish>:<path1> around anyway for the object name to be\n> useful, so there is no good reason why anybody should insist that\n> the plumbing level resolve <treeish>:<path1>//<path2> directly to an\n> object name in the first place.\n\nNot really.\n\nThe above means only that the support for new syntax would be not\nas easy as adding it to 'git rev-parse' (and it's built-in equivalent),\nexcept for the case where submodule uses the same object database as\nsupermodule.\n\nSo it wouldn't be as easy (on conceptual level) as adding support\nfor ':/<text>' or '<commit>^{/<text>}'.  It would be at least as\nhard, if not harder, as adding support for '@{-1}' and its '-'\nshortcut.\n\n\nJosh, what was the reason behind proposing this feature? Was it\nconceived as adding completeness to gitrevisions syntax, a low-hanging\nfruit?  It isn't (the latter).  Or was it some problem with submodule\nhandling that you would want to use this syntax for?\n\nAs for usefulness: this fills the hole in accessing submodules, one\nthat could be handled by combining plumbing-level commands.  Namely,\nthere are 5 states of submodule (as I understand it)\n\n * recorded in ref / commit in supermodule\n * recorded in the index in supermodule\n - recorded in ref / commit in submodule\n - recorded in the index in submodule\n - state of worktree in submodule\n\nThe last three can be easyly acessed by cd-ing to submodule.  The first\ntwo are not easy to get, AFAIUC.\n\n-- \nJakub Narębski\n"},{"id":"300052","messageId":"20160824142024.xnaehfo2spw26apj@x","threadId":"43898","inReplyTo":"b264e17a-12ff-69ca-f130-78d2635a0f85@gmail.com","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-08-24T14:20:24Z","receivedAt":"2016-08-24T14:42:57Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Wed, Aug 24, 2016 at 03:16:56PM +0200, Jakub Narębski wrote:\n> W dniu 24.08.2016 o 07:36, Junio C Hamano pisze:\n> > Jakub Narębski <jnareb@gmail.com> writes:\n> > \n> >> The point is that submodule has it's own object database.  It might\n> >> be the same as superproject's, but you need to handle submodule objects\n> >> being in separate submodule repository anyway.  Common repository is\n> >> just a special case.\n> >>\n> >> By the way, this also means that proposed \"extended extended SHA1\"\n> >> syntax would be useful to user's of submodules...\n> > \n> > Not really.\n> > \n> > I think that you gave a prime example why <treeish>:<path1>//<path2>\n> > is not a useful thing for submodules.  When the syntax resolves to a\n> > 40-hex object name, that object name by itself is not useful.\n> > \n> > You also need to carry an additional piece of information that lets\n> > you identify the location of the repository, in which the object\n> > name is valid, in the current user's context (i.e. somewhere in the\n> > superproject where the submodule lives).  In other words, you'd need\n> > to carry <treeish>:<path1> around anyway for the object name to be\n> > useful, so there is no good reason why anybody should insist that\n> > the plumbing level resolve <treeish>:<path1>//<path2> directly to an\n> > object name in the first place.\n> \n> Not really.\n> \n> The above means only that the support for new syntax would be not\n> as easy as adding it to 'git rev-parse' (and it's built-in equivalent),\n> except for the case where submodule uses the same object database as\n> supermodule.\n> \n> So it wouldn't be as easy (on conceptual level) as adding support\n> for ':/<text>' or '<commit>^{/<text>}'.  It would be at least as\n> hard, if not harder, as adding support for '@{-1}' and its '-'\n> shortcut.\n\nDepends on which cases you want to handle.  In the most general case,\nyou'd need to find and process the applicable .gitmodules file, which\nwould only work if you started from the top-level tree, not a random\ntreeish.  On the other hand, in the most general case, you don't\nnecessarily even have the module you need, because .git/modules only\ncontains the modules the *current* version needed, not every past\nversion.\n\nAs an alternate approach (pun intended): treat every module in\n.git/modules as an alternate and just look up the object by hash.  Or,\nteach git-submodule to store all the objects for submodules in the\nsupermodule's .git/objects (and teach git's reachability algorithm to\nrespect refs in .git/modules, or store their refs in\n.git/refs/submodules/ or in a namespace).\n\n> Josh, what was the reason behind proposing this feature? Was it\n> conceived as adding completeness to gitrevisions syntax, a low-hanging\n> fruit?  It isn't (the latter).  Or was it some problem with submodule\n> handling that you would want to use this syntax for?\n\nThis wasn't an abstract/theoretical completeness issue.  I specifically\nwanted this syntax for practical use with actual trees containing\ngitlinks, motivated by having a tool that creates and uses such\ngitlinks. :)\n\n> As for usefulness: this fills the hole in accessing submodules, one\n> that could be handled by combining plumbing-level commands.  Namely,\n> there are 5 states of submodule (as I understand it)\n> \n>  * recorded in ref / commit in supermodule\n>  * recorded in the index in supermodule\n>  - recorded in ref / commit in submodule\n>  - recorded in the index in submodule\n>  - state of worktree in submodule\n> \n> The last three can be easyly acessed by cd-ing to submodule.  The first\n> two are not easy to get, AFAIUC.\n\nRight.  I primarily care about those first two cases, especially the\nfirst one: given a commit containing a gitlink, how can I easily dig\ninto the linked commit?\n"},{"id":"300075","messageId":"CAGZ79kbz2WfbJ=uEV3irg8DREaEhJJzEX0_m9FGWiik8e9=w=g@mail.gmail.com","threadId":"43898","inReplyTo":"20160824142024.xnaehfo2spw26apj@x","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-08-24T16:26:30Z","receivedAt":"2016-08-24T16:26:38Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Aug 24, 2016 at 7:20 AM, Josh Triplett <josh@joshtriplett.org> wrote:\n> Depends on which cases you want to handle.  In the most general case,\n> you'd need to find and process the applicable .gitmodules file, which\n> would only work if you started from the top-level tree, not a random\n> treeish.  On the other hand, in the most general case, you don't\n> necessarily even have the module you need, because .git/modules only\n> contains the modules the *current* version needed, not every past\n> version.\n\nThe code in submodule-config.{c,h} allows exactly that:\n\n    submodule_from_path(commit_sha1, path)\n\nreturns information about the submodule recorded in a .gitmodules\nfile of a specific revision of the superproject.\n\nIdeally the .git/modules contains all the modules that existed, ever.\nWell \"ideally\" is the wrong word, but it is at least possible as the\nsubmodules git dir is kept even when you remove the outdated\nsubmodules working dir. (That's why the git dir is in the superprojects\ngit dir in the first place).\n\nBut as you say, it is possible of not having the submodule available.\n\n>\n> As an alternate approach (pun intended): treat every module in\n> .git/modules as an alternate and just look up the object by hash.  Or,\n> teach git-submodule to store all the objects for submodules in the\n> supermodule's .git/objects (and teach git's reachability algorithm to\n> respect refs in .git/modules, or store their refs in\n> .git/refs/submodules/ or in a namespace).\n\nThis is a sensible thing to do no matter the outcome of this discussion.\n\n>>  * recorded in ref / commit in supermodule\n>>  * recorded in the index in supermodule\n>>  - recorded in ref / commit in submodule\n>>  - recorded in the index in submodule\n>>  - state of worktree in submodule\n>>\n>> The last three can be easyly acessed by cd-ing to submodule.  The first\n>> two are not easy to get, AFAIUC.\n>\n> Right.  I primarily care about those first two cases, especially the\n> first one: given a commit containing a gitlink, how can I easily dig\n> into the linked commit?\n\nWhat do you exactly need? (What is digging here?)\n\nSee for example the series, that Jake Keller currently tries to land:\n    \"submodule inline diff format\"\nhttps://public-inbox.org/git/20160822234344.22797-1-jacob.e.keller@intel.com\n\nThat would enhance all the log/diff/show things.\n\nReading the original message, do you want to create patches in\nthe submodule from the superproject?\n\nThanks,\nStefan\n"},{"id":"300083","messageId":"165ac159-29e8-10d1-49ee-e5ff6543d0d2@gmail.com","threadId":"43898","inReplyTo":"20160824142024.xnaehfo2spw26apj@x","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-24T17:05:17Z","receivedAt":"2016-08-24T17:05:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 24.08.2016 o 16:20, Josh Triplett pisze:\n> On Wed, Aug 24, 2016 at 03:16:56PM +0200, Jakub Narębski wrote:\n[...]\n>> Not really.\n>>\n>> The above means only that the support for new syntax would be not\n>> as easy as adding it to 'git rev-parse' (and it's built-in equivalent),\n>> except for the case where submodule uses the same object database as\n>> supermodule.\n>>\n>> So it wouldn't be as easy (on conceptual level) as adding support\n>> for ':/<text>' or '<commit>^{/<text>}'.  It would be at least as\n>> hard, if not harder, as adding support for '@{-1}' and its '-'\n>> shortcut.\n> \n> Depends on which cases you want to handle.  In the most general case,\n> you'd need to find and process the applicable .gitmodules file, which\n> would only work if you started from the top-level tree, not a random\n> treeish.  On the other hand, in the most general case, you don't\n> necessarily even have the module you need, because .git/modules only\n> contains the modules the *current* version needed, not every past\n> version.\n\nThere is an additional problem, namely that directory with submodule\ncan be renamed.\n\nI don't know if there is an existing API, but assuming modern\ngit-submodule (with repository in .git/modules) you would have to\ndo the following steps for <revision>:<path/to/submodule>//<path>:\n\n * look up <revision>:.gitmodules for module which 'path'\n   is <path/to/submodule>; let's say it is named <submodule>\n * check if <revision>:<path/to/submodule> commit object\n   is present in .git/modules/<submodule>\n * look up this object\n\nIn the case of legacy submodule setup, with submodule repository\nin the supermodule working directory, you would need:\n   \n * look up <revision>:.gitmodules for module which 'path'\n   is <path/to/submodule>; let's say it is named <submodule>\n * look up current .gitmodules for current path of submodule\n   named <submodule>; let's say it is <new/path/submodule>\n * check of <revision>:</path/to/submodule> commit object\n   is present in :(top)<new/path/submodule>/.git repository\n * look up this object\n\nYou could also check if the submodule repository (as stored\nin config) is a path, and use it if it is... but that might\nbe going to far.\n\n\nBTW. all that reminds me that gitweb should handle submodules\nbetter.\n\n> As an alternate approach (pun intended): treat every module in\n> .git/modules as an alternate and just look up the object by hash.  \n\nThis could be a good fallback, to search through all submodules.\n\n> Or, teach git-submodule to store all the objects for submodules in the\n> supermodule's .git/objects (and teach git's reachability algorithm to\n> respect refs in .git/modules, or store their refs in\n> .git/refs/submodules/ or in a namespace).\n\nAnd fallback to this fallback could be searching through supermodule\nobject repository.\n\nStoring all objects in single repository is counter to the design\ndecision of submodules (though I don't remember what it was), but\nit might be done.  Still, Git needs to be able to deal with legacy\nsituations anyway.\n \n>> Josh, what was the reason behind proposing this feature? Was it\n>> conceived as adding completeness to gitrevisions syntax, a low-hanging\n>> fruit?  It isn't (the latter).  Or was it some problem with submodule\n>> handling that you would want to use this syntax for?\n> \n> This wasn't an abstract/theoretical completeness issue.  I specifically\n> wanted this syntax for practical use with actual trees containing\n> gitlinks, motivated by having a tool that creates and uses such\n> gitlinks. :)\n\nCould you explain what you need in more detail?  Is it a fragment\nof history of submodule, a contents of a file at given point of\nsuperproject history, diff between file-in-submodule and something\nelse, or what?\n \n>> As for usefulness: this fills the hole in accessing submodules, one\n>> that could be handled by combining plumbing-level commands.  Namely,\n>> there are 5 states of submodule (as I understand it)\n>>\n>>  * recorded in ref / commit in supermodule\n>>  * recorded in the index in supermodule\n>>  - recorded in ref / commit in submodule\n>>  - recorded in the index in submodule\n>>  - state of worktree in submodule\n>>\n>> The last three can be easyly acessed by cd-ing to submodule.  The first\n>> two are not easy to get, AFAIUC.\n> \n> Right.  I primarily care about those first two cases, especially the\n> first one: given a commit containing a gitlink, how can I easily dig\n> into the linked commit?\n\nAll right.\n\nThough you can cobble it with plumbing... just saying.\n\n-- \nJakub Narębski\n\n"},{"id":"300111","messageId":"20160824202133.olvifmet3g4yeswr@x","threadId":"43898","inReplyTo":"165ac159-29e8-10d1-49ee-e5ff6543d0d2@gmail.com","subject":"Re: Extending \"extended SHA1\" syntax to traverse through gitlinks?","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-08-24T20:21:33Z","receivedAt":"2016-08-24T20:22:32Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Wed, Aug 24, 2016 at 07:05:17PM +0200, Jakub Narębski wrote:\n> W dniu 24.08.2016 o 16:20, Josh Triplett pisze:\n> > On Wed, Aug 24, 2016 at 03:16:56PM +0200, Jakub Narębski wrote:\n> [...]\n> >> Not really.\n> >>\n> >> The above means only that the support for new syntax would be not\n> >> as easy as adding it to 'git rev-parse' (and it's built-in equivalent),\n> >> except for the case where submodule uses the same object database as\n> >> supermodule.\n> >>\n> >> So it wouldn't be as easy (on conceptual level) as adding support\n> >> for ':/<text>' or '<commit>^{/<text>}'.  It would be at least as\n> >> hard, if not harder, as adding support for '@{-1}' and its '-'\n> >> shortcut.\n> > \n> > Depends on which cases you want to handle.  In the most general case,\n> > you'd need to find and process the applicable .gitmodules file, which\n> > would only work if you started from the top-level tree, not a random\n> > treeish.  On the other hand, in the most general case, you don't\n> > necessarily even have the module you need, because .git/modules only\n> > contains the modules the *current* version needed, not every past\n> > version.\n> \n> There is an additional problem, namely that directory with submodule\n> can be renamed.\n> \n> I don't know if there is an existing API, but assuming modern\n> git-submodule (with repository in .git/modules) you would have to\n> do the following steps for <revision>:<path/to/submodule>//<path>:\n> \n>  * look up <revision>:.gitmodules for module which 'path'\n>    is <path/to/submodule>; let's say it is named <submodule>\n>  * check if <revision>:<path/to/submodule> commit object\n>    is present in .git/modules/<submodule>\n>  * look up this object\n\nThis also assumes your lookup started with a <committish> and not an\nintermediate <treeish>, but that'll work in many cases.\n\n> > As an alternate approach (pun intended): treat every module in\n> > .git/modules as an alternate and just look up the object by hash.  \n> \n> This could be a good fallback, to search through all submodules.\n> \n> > Or, teach git-submodule to store all the objects for submodules in the\n> > supermodule's .git/objects (and teach git's reachability algorithm to\n> > respect refs in .git/modules, or store their refs in\n> > .git/refs/submodules/ or in a namespace).\n> \n> And fallback to this fallback could be searching through supermodule\n> object repository.\n\nI'd flip those around: first search registered .gitmodules, then look up\nthe object in the superproject (since you have it at hand), and then\nmaybe search every submodule.\n\n> >> Josh, what was the reason behind proposing this feature? Was it\n> >> conceived as adding completeness to gitrevisions syntax, a low-hanging\n> >> fruit?  It isn't (the latter).  Or was it some problem with submodule\n> >> handling that you would want to use this syntax for?\n> > \n> > This wasn't an abstract/theoretical completeness issue.  I specifically\n> > wanted this syntax for practical use with actual trees containing\n> > gitlinks, motivated by having a tool that creates and uses such\n> > gitlinks. :)\n> \n> Could you explain what you need in more detail?  Is it a fragment\n> of history of submodule, a contents of a file at given point of\n> superproject history, diff between file-in-submodule and something\n> else, or what?\n\nAs part of git-series, I have commits, whose trees contain various\ngitlinks, such as \"series\" and \"base\".  Those gitlinks point to commits\nin the same repository.  I'd like to use those gitlinks everywhere I\ncould use any other committish, such as a branch name.  In particular,\nI'd like to write things like some_feature:series:path/to/file (\"what\ndoes path/to/file look like in the current version of some_feature\"),\nsome_feature:series^ (\"what's the second-to-last commit in\nsome_feature\"), some_feature~5:series:path/to/file (\"what did\npath/to/file look like in an older version of some_feature\"), or\nsome_feature~5:base..some_feature~5:series~2 (\"all but the last two\npatches in some_feature~5\").  Those should work with show, diff,\nformat-patch, log, etc.\n\n> >> As for usefulness: this fills the hole in accessing submodules, one\n> >> that could be handled by combining plumbing-level commands.  Namely,\n> >> there are 5 states of submodule (as I understand it)\n> >>\n> >>  * recorded in ref / commit in supermodule\n> >>  * recorded in the index in supermodule\n> >>  - recorded in ref / commit in submodule\n> >>  - recorded in the index in submodule\n> >>  - state of worktree in submodule\n> >>\n> >> The last three can be easyly acessed by cd-ing to submodule.  The first\n> >> two are not easy to get, AFAIUC.\n> > \n> > Right.  I primarily care about those first two cases, especially the\n> > first one: given a commit containing a gitlink, how can I easily dig\n> > into the linked commit?\n> \n> All right.\n> \n> Though you can cobble it with plumbing... just saying.\n\nSure, but that makes the expression much more complex.\n"}]}