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:
>> 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:
>>>>>
[...]
>>>> 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...
>>>> 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/
>> 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
--
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