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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html