On Tue, Jul 29, 2008 at 05:51:31AM +0000, Benjamin Collins wrote:
> I try to keep all my submodules on (no branch) as much as possible.
> In a way, I feel like that kind of relieves me of the chore of keeping
> mapping superproject branches to submodule branches in my head.
Why would _you_ map them to superproject branches ? I mean it's pretty
much Git's matter. In fact, maybe calling them branches is not a
brilliant idea, what I would like would probably rather be some kind of
reflog like thing, but with one reflog per submodule and supermodule
branch.
I agree with you than when you don't have to do any change in the
submodule, detached HEADs just work. But when you often have to push
fixes in, it's a nightmare. Instead of just having to:
$EDITOR mysubmodule/file.c
git commit mysubmodule/file.c # that would ideally do a commit in the
# submodule then update the submodule
# state in the supermodule
git submodule mysubmodule push origin HEAD # push the submodule mysubmodule
# changes to the appropriate branch
git push origin HEAD
You have to:
cd submodule
git branch -D master
git checkout -b master
git commit file.c
cd ..
git commit submodule
cd submodule
git push origin HEAD:remote/branch/we/want/to/push/to
cd ..
git push origin HEAD
*phew*
I'm sorry but this is nowhere near a good UI. Of course the detached
head *currently* prevents you to shoot yourself in the foot, because
submodules are _that_ dangerous. But those also are tedious to work
with, like a lot, which makes currently our answer to big projects "do
not have GB-big repositories, split them in submodules" a bad joke,
because their ergonomy is nowhere near what you have with a monolithic
repository yet.
I'm trying to see what to do better. I believe we _need_ those things:
* a way to name the successive states of the submodule, a branch looks
like a good idea, but maybe we can "invent" some different idea so
that it looks and tastes like a branch, but is more automagic in the
sense that it's just a prettier name than a sha1.
This would allow to inspect the submodule history using
`gitk $this_name`. The $PS1 thing is nice, but you have to cd into
the submodule to see where it currently lives. So you rather need
something else.
* a way to remember where you want to push changes you do in the
submodule to. That's a bit like branch tracking, but not quite. This
is required so that we can (and I strongly believe we want that in
the end) make many porcelain commands act on the full
(super+sub)modules in a unified way, somehow hiding the submodules
boundaries.
For example, git commit file1 file2 file3 ... would do the
submodules commits if any, and then the supermodule one. Alternatively, if
you have e.g.:
$ git add mysubmodule/file1.c
$ git add superfile.c
$ git add mysubmodule # tell the supermodule we want to commit what
# is in the submodule index at the same time
$ git commit
Then if you run:
$ git push # fails complaining that mysubmodule is
# not pushed
$ git submodule mysubmodule push
$ git push # works
* What you "track" must be a per supermodule branch thing, so that if
you do things like that:
# you are in master in the supermodule with non pushed commits in
# the submodule
<.. oh crap there is a bug in the supermodule that I need to fix in
the production branch..>
$ git checkout production # would checkout in the submodule what
# matches
$ $EDITOR mysubmodule/something
$ git commit !$
$ ..push everything..
<.. okay let's now go back to master ..>
$ git checkout master
<... hack hack hack to finish the current WIP ...>
<... okay we're ready to merge production in ...>
$ git merge production # will DWYM with the submodules, IOW merge the
# `production` state into the current `master` one.
$ git sm mysubmodule push
$ git push
Try to write the same workflow with the current submodules, you'll
end up with a script at least 3 times as long, because you would
need to do everything by hand, including switching submodules,
naming temporary branches in them so that you can work decently and
perform the merges and so on.
--
·O· Pierre Habouzit
··O madcoder@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgp9dxiRqLR4E.pgp
Description: PGP signature
