From: Jakub Narębski Date: Wed, 24 Aug 2016 13:16:56 GMT Subject: Re: Extending "extended SHA1" syntax to traverse through gitlinks? Message-ID: In-Reply-To: W dniu 24.08.2016 o 07:36, Junio C Hamano pisze: > Jakub Narębski writes: > >> 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... > > Not really. > > I think that you gave a prime example why :// > is not a useful thing for submodules. When the syntax resolves to a > 40-hex object name, that object name by itself is not useful. > > You also need to carry an additional piece of information that lets > you identify the location of the repository, in which the object > name is valid, in the current user's context (i.e. somewhere in the > superproject where the submodule lives). In other words, you'd need > to carry : around anyway for the object name to be > useful, so there is no good reason why anybody should insist that > the plumbing level resolve :// directly to an > object name in the first place. Not really. The above means only that the support for new syntax would be not as easy as adding it to 'git rev-parse' (and it's built-in equivalent), except for the case where submodule uses the same object database as supermodule. So it wouldn't be as easy (on conceptual level) as adding support for ':/' or '^{/}'. It would be at least as hard, if not harder, as adding support for '@{-1}' and its '-' shortcut. Josh, what was the reason behind proposing this feature? Was it conceived as adding completeness to gitrevisions syntax, a low-hanging fruit? It isn't (the latter). Or was it some problem with submodule handling that you would want to use this syntax for? As for usefulness: this fills the hole in accessing submodules, one that could be handled by combining plumbing-level commands. Namely, there are 5 states of submodule (as I understand it) * recorded in ref / commit in supermodule * recorded in the index in supermodule - recorded in ref / commit in submodule - recorded in the index in submodule - state of worktree in submodule The last three can be easyly acessed by cd-ing to submodule. The first two are not easy to get, AFAIUC. -- Jakub Narębski