On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote:
> 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
Interesting point; if extending this syntax anyway, any treeish ought to
work, not just a committish.
> Though you can do resolve step manually
>
> $ git cat-file -p $(git rev-parse HEAD:subdir):file
>
> This works.
True, but that seems quite inconvenient.
> > 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.
Only if the gitlink points to a commit that doesn't exist in the same
repository. A gitlink can point to a commit you already have.
> 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?
It seems as visible as the standard commit:path syntax; the second colon
seems just as visible as the first. :/ already has a different meaning
(text search), so that would introduce inconsistency.
> > (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
I stand corrected; I didn't find that. I thought rev parsing worked
independently from the repository, and didn't have any automagic
detection based on the contents of the repository?
This seems ambiguous, and (AFAICT) not documented. If HEAD:A and B both
refer to a commit, in addition to the blob A..B, which will HEAD:A..B
refer to? I did test the HEAD:gitlink..anotherbranch case, and it does
parse as a range.
--
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