Re: Extending "extended SHA1" syntax to traverse through gitlinks?
W dniu 23.08.2016 o 08:53, Josh Triplett pisze:
Show 5 quoted lines
> 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:
>>> 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:
>>>>>
Show 23 quoted lines
>>>> 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...
Show 12 quoted lines
>>>> 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/
Show 5 quoted lines
>> 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.
Show 5 quoted lines
> 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/submoduleBut 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
Josh Triplett
