Martin Waitz wrote:
hoi :)
On Fri, Dec 01, 2006 at 02:05:33PM +0100, sf wrote:
On Fri, Dec 01, 2006 at 01:09:49PM +0100, sf wrote:
Martin Waitz wrote:
So you not only store your submodule HEAD commit in the supermodule
when you do commit to the supermodule, it also means that your
submodule HEAD will be updated when you update your supermodule.
Why the magic? The typical workflow in git is
1. You work on a branch, i.e. edit and commit and so on.
2. At some point, you decide to share the work you did on that branch
(e-mail a patch, merge into another branch, push upstream or let it by
pulled by upstream)
3. Other people want to use your new work.
Sorry, if that was not obvious: You actually procceed with one of the
options I listed in Step 2. What I wanted to state is that with git you
do not mix up committing (which is local to your repository and your
branch) and publishing.
I guess you are refering to not mix up committing to the submodule and
updating the supermodule index.
These are really two separate steps, I just combined them above because I
wanted to put emphasis on the other part: it is not a one-way flow, it
is bidirectional, so your HEAD would have to changed if the supermodule
gets updated.
And I consider changing HEAD, without looking at the branch it points
to, to be a bad thing.
So a commit in the supermodule turns into a commit in the submodule?
That's just plain wrong. If it doesn't, why would the submodule HEAD
have to change?
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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