Re: RFC: Making submodules "track" branches
- From
Steven Michalske <smichalske@gmail.com>
- Date
- Jun 9, 2010, 12:47 UTC
- Message-ID
- <C0EA2469-DA5B-413E-9AB4-F79954DBE3AE@gmail.com>
- In-Reply-To
- <201006091022.18896.johan@herland.net>
On Jun 9, 2010, at 1:22 AM, Johan Herland wrote:
Show 64 quoted lines
> On Wednesday 09 June 2010, Jens Lehmann wrote:
>> Am 08.06.2010 23:52, schrieb Johan Herland:
>>> The good thing with Ævar's approach is that this is all configurable
>>> per branch (indeed, per commit[1]) by editing your .gitmodules file.
>>
>> Yep, I think this is the sane way to do that.
>>
>>> Interesting. Will the object parsing machinery handle that without
>>> hiccups? What if an older Git version tries to checkout/update a
>>> submodule with a 0- hash?
>>
>> Maybe Ævar's idea of dropping such a submodule from the tree is
>> better.
>
> Agreed. That will of course cause older Git versions to skip the
> submodule
> altogether, which is probably the safest failure mode.
>
>>> Me too, but I suspect that if you draw the "one big repo" approach
>>> to
>>> its logical conclusion, there will be some demand for recursive
>>> commits.
>>
>> You may be right here. But as submodules often have a detached
>> HEAD, this
>> might get interesting ;-)
>
> Yes, trying to recursively commit across a submodule with detached
> HEAD
> should obviously fail (at least by default). But as long as a local
> branch
> is checked out in the submodule (which is not necessarily the same
> as having
> the submodule _track_ that branch), a recursive commit should be
> relatively
> straightforward.
>
>>> [1]: Say your submodule usually tracks a branch, but you're creating
>>> some tag in the super-repo, and you want that tag to uniquely
>>> identify
>>> the submodule. You achieve this by making sure the tagged commit
>>> removes the relevant "branch = whatever" line from .gitmodules, and
>>> records the appropriate submodule version in the super-repo tree.
>>> Then, you can revert the .gitmodules change on the next commit to
>>> resume tracking the submodule branch.
>>>
>>> Now, whenever you checkout the tag, you will always get the exact
>>> same
>>> version of the submodule, although the submodule otherwise tracks
>>> some
>>> branch.
>>
>> Won't work anymore when we would use 0{40} or drop it from the tree.
>> AFAICS always-tip and referencing a certain commit don't mix well.
>
> AFAICS, it would still work as long as it exists in the tree for that
> specific commit (but is missing/0{40} in other commits).
>
> We're not mixing "always-tip" and "exact-commit" in the same commit.
> We use
> "always-tip" in regular commits, and then temporarily switch to
> "exact-
> commit" in the commits where a certain submodule version is required.
>When making a tag, could the notes system be used for marking what commit was exactly on the submodule, perhaps include the closest remote commits as well?
Something like
Submodule Status: ["foo"] branch = subtopic:SHA
This assumes that git notes are shared/cloned......
Other thoughts.
Things that should still work with tracking submodules. - bisect - Must be able to identify that a submodule change introduced the bug. - archive - Should it use the version from the commit, or the latest? - rebase - update all of the submodule commits? - checkout - tip vs commit - reset --hard - Good question... not sure.... probably depend on tip vs commit like checkout. - More????
I would rather the submodule entree in the tree be always updated to what is in the submodule on the commit, so that the history is always there. Then actions updating the repository from remotes automatically pull the latest version. I feel that the submodule if automatically be pulled, merged, etc, than the submodule should get a commit, with the message about this being an automatic update of the submodule. Checking out is a different story.... checking out a branch tip of the super gets the latest tip from the submodule. When you commit, the submodule gets it's auto commit, then a second commit for the code changes. checking out a previous revision should probably put the sub module to the state it was in at that point in time. Creating a branch and adding new content would update according to the rules. but show the change of the subproject as from the super's at the branch point, not the tip.
This way older gits have a submodule to work with and newer gits will do the right thing.
Example:
s-y-y-z A-B-C-D \ \F-G s-z-z
F is branched when the latest sub module is at z but shows the change from s not z because A the parent of F was created with the submodule at s
Situational Example:
I am developing away and as I progress in development I get a regression bug, so I run git bisect from the last stable release with out this bug, and it starts bisecting away.
In the mode where we don't store the state of the project I can't bisect the changes against the subproject, where my bug might have been introduced from.
So that issue should be probably handled in the git bisect code, that is "Make git bisect submodule aware" in more verbose terms, when bisecting a super project the sub modules should undergo bisection as well. This is a permutation that will expand rapidly, but some thoughts on how to dig into the bisection issues. This is another email ;-)
Rebase: With the auto commit of submodule scheme, a rebase would change the tracking branches to the latest of the tracked version. and auto merge and record the previous submodule revision in the commit message of the submodule auto commit.
Checkout with nonexistant submodule sha: This is the case where the submodules ref was not pushed publicly, so, the contents are not available. You get a nice warning and the tip of the submodules branch gets checked out for that submodule.
Steve