W dniu 21.08.2016 o 00:50, Josh Triplett pisze: > Currently, if you have a branch "somebranch" that contains a gitlink > "somecommit", you can write "somebranch:somecommit" to refer to the > commit, just like a tree or blob. ("man git-rev-parse" defines this > syntax in the "SPECIFYING REVISIONS" section.) You can use this > anywhere you can use a committish, including "git show > somebranch:somecommit", "git log somebranch:somecommit..anotherbranch", > or even "git format-patch -1 somebranch:somecommit". > > However, you cannot traverse *through* the gitlink to look at files > inside its own tree, or to look at other commits relative to that > commit. For instance, "somebranch:somecommit:somefile" and > "somebranch:somecommit~3" do not work.
Note that there is the same problem traversing through trees: while 'git cat-file -p HEAD:subdir/file' works, the 'HEAD:subdir:file' doesn't: $ git cat-file -p HEAD:subdir:file fatal: Not a valid object name HEAD:subdir:file Though you can do resolve step manually $ git cat-file -p $(git rev-parse HEAD:subdir):file This works. > > I'd love to have a syntax that allows traversing through the gitlink to > other files or commits. Ideally, I'd suggest the syntax above, as a > natural extension of the existing extended syntax. And with the above manual resolving, you can see the problem with implementing it: the git-cat-file (in submodule) and git-rev-parse (in supermodule) are across repository boundary. Also the problem with proposed syntax is that is not very visible. But perhaps it is all right. Maybe :/ as separator would be better, or using parentheses or braces? > (That syntax would potentially introduce ambiguity if you had a file > named "somecommit:somefile" or "somecommit~3". That doesn't seem like a > problem, though; the existing syntax already doesn't support accessing a > file named "x..y" or "x...y", so scripts already can't expect to access > arbitrary filenames with that syntax without some kind of quoting, which > we also don't have.) Errr... what? $ echo A..B >A..B $ git add A..B $ git commit -m 'A..B added' [master 2d69af9] A..B added 1 file changed, 1 insertion(+), 1 deletion(-) create mode 100644 A..B $ git show HEAD:A..B A..B > > Does this seem reasonable? Would a patch introducing such syntax > (including documentation and tests) be acceptable? -- Jakub Narębski -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html