On Wed, Aug 24, 2016 at 07:05:17PM +0200, Jakub Narębski wrote:
> W dniu 24.08.2016 o 16:20, Josh Triplett pisze:
> > On Wed, Aug 24, 2016 at 03:16:56PM +0200, Jakub Narębski wrote:
> [...]
> >> 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 ':/<text>' or '<commit>^{/<text>}'. It would be at least as
> >> hard, if not harder, as adding support for '@{-1}' and its '-'
> >> shortcut.
> >
> > Depends on which cases you want to handle. In the most general case,
> > you'd need to find and process the applicable .gitmodules file, which
> > would only work if you started from the top-level tree, not a random
> > treeish. On the other hand, in the most general case, you don't
> > necessarily even have the module you need, because .git/modules only
> > contains the modules the *current* version needed, not every past
> > version.
>
> There is an additional problem, namely that directory with submodule
> can be renamed.
>
> I don't know if there is an existing API, but assuming modern
> git-submodule (with repository in .git/modules) you would have to
> do the following steps for <revision>:<path/to/submodule>//<path>:
>
> * look up <revision>:.gitmodules for module which 'path'
> is <path/to/submodule>; let's say it is named <submodule>
> * check if <revision>:<path/to/submodule> commit object
> is present in .git/modules/<submodule>
> * look up this object
This also assumes your lookup started with a <committish> and not an
intermediate <treeish>, but that'll work in many cases.
> > As an alternate approach (pun intended): treat every module in
> > .git/modules as an alternate and just look up the object by hash.
>
> This could be a good fallback, to search through all submodules.
>
> > Or, teach git-submodule to store all the objects for submodules in the
> > supermodule's .git/objects (and teach git's reachability algorithm to
> > respect refs in .git/modules, or store their refs in
> > .git/refs/submodules/ or in a namespace).
>
> And fallback to this fallback could be searching through supermodule
> object repository.
I'd flip those around: first search registered .gitmodules, then look up
the object in the superproject (since you have it at hand), and then
maybe search every submodule.
> >> 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?
> >
> > This wasn't an abstract/theoretical completeness issue. I specifically
> > wanted this syntax for practical use with actual trees containing
> > gitlinks, motivated by having a tool that creates and uses such
> > gitlinks. :)
>
> Could you explain what you need in more detail? Is it a fragment
> of history of submodule, a contents of a file at given point of
> superproject history, diff between file-in-submodule and something
> else, or what?
As part of git-series, I have commits, whose trees contain various
gitlinks, such as "series" and "base". Those gitlinks point to commits
in the same repository. I'd like to use those gitlinks everywhere I
could use any other committish, such as a branch name. In particular,
I'd like to write things like some_feature:series:path/to/file ("what
does path/to/file look like in the current version of some_feature"),
some_feature:series^ ("what's the second-to-last commit in
some_feature"), some_feature~5:series:path/to/file ("what did
path/to/file look like in an older version of some_feature"), or
some_feature~5:base..some_feature~5:series~2 ("all but the last two
patches in some_feature~5"). Those should work with show, diff,
format-patch, log, etc.
> >> 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.
> >
> > Right. I primarily care about those first two cases, especially the
> > first one: given a commit containing a gitlink, how can I easily dig
> > into the linked commit?
>
> All right.
>
> Though you can cobble it with plumbing... just saying.
Sure, but that makes the expression much more complex.
--
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