Catalin Marinas wrote:
Show 5 quoted lines
>> >>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.
Show 9 quoted lines
> >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.
Show 11 quoted lines
>>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 with both stable and develop lines ( qgit or StGIT ;-) projects like ).
You clarified me for both cases.
Thanks Marco
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com