Re: RFC: Making submodules "track" branches

[Steven Michalske <smichalske@gmail.com>]

On Jun 9, 2010, at 1:22 AM, Johan Herland wrote:

> 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