Re: [RFC] Patches exchange is bad?

Catalin Marinas wrote:

quoted

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.

quoted

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