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.
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.
(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, wich
we also don't have.)
Does this seem reasonable? Would a patch introducing such syntax
(including documentation and tests) be acceptable?
- Josh Triplett
From: Jakub Narębski <hidden> Date: 2016-08-21 13:49:31
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.)
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:
quoted
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.
quoted
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.
quoted
(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.)
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.
From: Jakub Narębski <hidden> Date: 2016-08-22 18:39:54
W dniu 21.08.2016 o 16:26, Josh Triplett pisze:
On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote:
quoted
W dniu 21.08.2016 o 00:50, Josh Triplett pisze:
quoted
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.
Actually, because you can use simply "HEAD:subdir/file" I'd rather
it didn't work (no two ways of access), unless we can get it for free.
quoted
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.
Especially that for submodules you need:
$ git --git-dir=subdir/.git cat-file -p $(git rev-parse HEAD:subdir):file
(or something like that), assuming that you start in supermodule.
quoted
quoted
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.
The idea of submodules is that tree object in superproject includes
link to commit of subproject (so called gitlink). Tree object is
in superproject repository, while gitlinked commit is in submodule
repository.
True, with modern Git the submodule repository is embedded in .git
area of superproject, with '.git' in submodule being gitling file,
but by design those objects are in different repositories, in different
object databases.
quoted
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.
Actually ":/" has a special meaning only if it is at beginning:
- :/<text> for first matching commit from any ref
- :/ is 'top directory' pathspec (equivalent to ':(top)')
But perhaps '//' would be better.
quoted
quoted
(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.)
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?
It probably depends on whether command expects range (like git-log),
supports range-like notation (like git-diff), or expects single or
multiple things (like git-show).
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.
Well, it is ambiguous.
We would probably want to support some kind of quoting, for example
HEAD:"A..B" (where everything inside "..." is c-quoted, but can use utf-8).
--
Jakub Narębski
On Mon, Aug 22, 2016 at 08:39:19PM +0200, Jakub Narębski wrote:
W dniu 21.08.2016 o 16:26, Josh Triplett pisze:
quoted
On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote:
quoted
W dniu 21.08.2016 o 00:50, Josh Triplett pisze:
quoted
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.
Actually, because you can use simply "HEAD:subdir/file" I'd rather
it didn't work (no two ways of access), unless we can get it for free.
Agreed. I suspect we'd get it for free if we introduced a syntax for
traversing through commits (by allowing that syntax to work with any
treeish), but if not, I certainly don't see any value in adding a second
syntax for accessing tree contents.
quoted
quoted
quoted
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.
The idea of submodules is that tree object in superproject includes
link to commit of subproject (so called gitlink). Tree object is
in superproject repository, while gitlinked commit is in submodule
repository.
True, with modern Git the submodule repository is embedded in .git
area of superproject, with '.git' in submodule being gitling file,
but by design those objects are in different repositories, in different
object databases.
git-submodule handles them that way by default, yes. But a gitlink
doesn't inherently have to point to a separate repository, and even a
submodule could point to an object available in the same repository
(perhaps via another ref).
git-series creates such gitlinks, for instance.
quoted
quoted
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.
Actually ":/" has a special meaning only if it is at beginning:
True, but it seems inconsistent to have :/ mean search if at the
beginning, or traversal if not.
But perhaps '//' would be better.
That does seem unambiguous, and it can't conflict with an existing file.
Does it seem reasonable to allow that for the initial commit as well
('committish//file', as well as 'commit//gitlink//file')?
Also, while that handles traversal into the tree contained in the
gitlinked commit, what about navigating by commit (using '~' and '^',
for instance)? Does it seem reasonable to allow those as well, perhaps
only if you use // to reach the gitlink? For instance,
'commit//gitlink~3', or 'commit//gitlink^{tree}'?
From: Jakub Narębski <hidden> Date: 2016-08-23 20:25:03
W dniu 23.08.2016 o 08:53, Josh Triplett pisze:
On Mon, Aug 22, 2016 at 08:39:19PM +0200, Jakub Narębski wrote:
quoted
W dniu 21.08.2016 o 16:26, Josh Triplett pisze:
quoted
On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote:
quoted
W dniu 21.08.2016 o 00:50, Josh Triplett pisze:
quoted
[...]
quoted
quoted
quoted
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.
The idea of submodules is that tree object in superproject includes
link to commit of subproject (so called gitlink). Tree object is
in superproject repository, while gitlinked commit is in submodule
repository.
True, with modern Git the submodule repository is embedded in .git
area of superproject, with '.git' in submodule being gitling file,
but by design those objects are in different repositories, in different
object databases.
git-submodule handles them that way by default, yes. But a gitlink
doesn't inherently have to point to a separate repository, and even a
submodule could point to an object available in the same repository
(perhaps via another ref).
git-series creates such gitlinks, for instance.
The point is that submodule has it's own object database. It might
be the same as superproject's, but you need to handle submodule objects
being in separate submodule repository anyway. Common repository is
just a special case.
By the way, this also means that proposed "extended extended SHA1"
syntax would be useful to user's of submodules...
quoted
quoted
quoted
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.
Actually ":/" has a special meaning only if it is at beginning:
True, but it seems inconsistent to have :/ mean search if at the
beginning, or traversal if not.
Right. It would also mean that if we have directory or submodule
called 'foo:', then 'foo:/bar' would be ambiguous where it was not
before.
BTW. currently there is not much need for quoting, at least not for
the ':' as separator. Files with ':' in them, even if they are
named 'HEAD:foo' can be distinguished with ./HEAD:foo, or with
':(top)HEAD:foo'. This would not be the case if supermodule to
submodule separator was ':'; the '//' is safe-ish.
Also, '//' would have additional meaning, in that left hand side
and right hand side are in [possibly] different repositories.
Sidenote (on MS Windows):
samsung@notebook MINGW64 ~/test (master)
$ echo 'HEAD:A..B' >'HEAD:A..B'
samsung@notebook MINGW64 ~/test (master)
$ git add 'HEAD:A..B'
fatal: pathspec 'HEAD:A..B' did not match any files
samsung@notebook MINGW64 ~/test (master)
$ ls
A A..B B HEAD:A..B file sub/ subm/
quoted
But perhaps '//' would be better.
That does seem unambiguous, and it can't conflict with an existing file.
Does it seem reasonable to allow that for the initial commit as well
('committish//file', as well as 'commit//gitlink//file')?
I don't think we can change this without breaking scripts (because it
would be breaking backward compatibility). And adding new syntax...
The problem might be shells sanitizing input, that is turning '//'
into '/' before passing it to command; I don't know if it is a problem.
Probably not.
Also, while that handles traversal into the tree contained in the
gitlinked commit, what about navigating by commit (using '~' and '^',
for instance)? Does it seem reasonable to allow those as well, perhaps
only if you use // to reach the gitlink? For instance,
'commit//gitlink~3', or 'commit//gitlink^{tree}'?
I don't know which of those work, and which do not:
HEAD:path/to/submodule~3
:0:path/to/submodule^{tree}
HEAD~3:path/to/submodule
But I think the following should work:
v1.0.1~2^2~4:path/to/submodule~3//inner/subm~4//sub/file
NOTE that the syntax allows to start at revision, at the index state
of superproject, but it only goes to state recorder, or to be recorded
in the superproject. There is no syntax to find out HEAD or index
version of submodule, unless you are within submodule, isn't it?
Best,
--
Jakub Narębski