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

Reply via email to