Avery Pennarun wrote:
> Instead of storing only the commitid of each submodule in the parent
> tree, store the current branch name as well.
That goes quite against the fundamental design of git submodules in that
the submodules are by themselves independent entities.
Not sure what you mean here; the supermodule already stores the
commitid of the submodule. All I'm proposing is that it also store
the default branchname (ie. the branchname that the submodule was
using when its gitlink was checked into the supermodule) along with
that commitid. The submodule never knows anything about the
supermodule.
How about this.
This could be an optional disambiguator in .gitmodules in the
superproject, to allow you to "store the branch it was made from". Glue
to make this automatic/easy optional.
When updating a submodule, with an option set (or configured; which
might even later become a default if people like it enough), it will try
to figure out a reasonable branch for that commit, using git-name-rev,
and check out the branch with that name. It first uses the hint above
as an argument to git-name-rev --refs=XX, and if that doesn't provide a
reasonable answer then look for any branch.
I think this approach would not get in the way of people who don't want
to use it, and provide for making things automatic for those who want that.
I agree that the submodule should have its HEAD pointing at exactly
the superproject-specified commit. However, I believe this commit
should have a local branch name (in the subproject) attached to it, or
else (as I and my co-workers have frequently experienced) people will
accidentally check in to a nameless branch, causing 'git push' to
silently not upload anything, and thus lose track of their commits. I
have lost work this way.
I think this is a separate argument against git-push, the default
behaviour of which also causes me to tell people not to use the
argument-less form of git-push until they understand how to use the
two-argument form.
In the context of git-submodule, adding features to it to avoid this if
that is the way that the user wants to work would be good IMHO.
The idea of naming the local-subproject-branch with the same name as
it had on checking is that then "git pull" in the subproject will work
exactly as expected:
It's not really the local branch name anyway, it's how the default push
gets configured; perhaps it's worth distinguishing which part you are
interested in.
The super-summary of all that is I think I'd like to make three git
changes here:
1) When checking out a submodule from scratch, use the local
supermodule as a --alternate. That way if both super and submodule
are hosted in the same remote repo, I don't have to clone them twice.
(And cloning my local repo to another copy doesn't stop git-submodule
from working.)
Yes - you've already seen the SoC plan for that, although I believe no
students applied for that one, and if you think it's minor enough to do,
great.
2) When checking out a submodule, give the submodule's current commit
a useful branch name (ideally, the name it had when the gitlink was
checked into the supermodule). When updating a submodule with
git-submodule-update, quietly fixup the submodule's local branch ref
if it hasn't been changed; else produce a conflict of some sort.
See above for how I think that should work.
3) Bonus: make "git push" operate recursively on submodules, and "git
pull" automatically run git-submodule-update.
I'd appreciate that feature - though I'm more interested in making sure
that I don't push anything where the submodule commit is not available
via the URL listed in .gitmodules.
Presuming such a check, would that check happen at push time, or do you
check at a different time, such as when committing, or when adding the
submodule to the index?
I think checking that referential integrity is something perhaps easier
to bite off and get people to agree on. I think it would solve the
overall process problem, by forcing people to push the submodule before
the commit of the superproject can succeed without forcing.
Thoughts/comments?
Sam
--
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
