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