Catalin Marinas wrote:
>>If I uderstand correctly you never commit patches from StGIT stack directly
>>in your base git repository, in this example git HEAD, but you always round
>>trip to MAIN.
When I say 'you always round trip to MAIN', I mean you send patches
upstream and someone commits to MAIN, then you pull from MAIN.
Sorry if it was not clear.
>One usually doesn't maintain MAIN. That's an example for the Linux
>kernel development where you can't control what get merged into MAIN.
>There is a bit of confusion here since you said in a previous e-mail
>that more people can commit to the stable branch. In this case, you
>would need a separate repository for stable with a maintainer pulling
>changes from others.
When I said 'more people can commit to the stable branch' I meant more
people sends patches to a mantainer that commits the patches in a stable branch.
Sorry, peraphs also this was not clearly expressed.
>>Then you don't have two git repository: HEAD and MAIN
>>Infact there is only one git repository, MAIN, cloned on your box
>>and called HEAD and with a StGIT stack added on top.
>The StGIT usage idea is that you only know what patches you have on
>top of a main repository. Since you expect your patches to be merged
>upstream or just updated every time the main repository changes, it
>might not make sense to commit the patches onto the base.
Yes, you better explained what I was badly trying to say before.
>I need a bit more clarification about your work flow.
I was thinking at two different kind of workflow, one were you are tracking a
remote repository ( Linux kernel project like ) and one as single developer
both stable and develop lines ( qgit or StGIT ;-) projects like ).
You clarified me for both cases.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html