Re: RFC: Making submodules "track" branches

On Wednesday 09 June 2010, Jens Lehmann wrote:

Am 08.06.2010 23:52, schrieb Johan Herland:

quoted

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.

quoted

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.

quoted

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.

quoted

[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.


...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net