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.
The opposite: If you work in the supermodule, even if it is in the code
of the submodule, you only commit to the supermodule. The submodule does
not "know" about these changes after step 1.
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.
Why do you mix up supermodule and submodule? The way I see your proposal
you cannot change submodule and supermodule independently. That is a
huge drawback.
Regards
Stephan
-
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