Abdelrazak Younes wrote: > That's the key point: casual contributor won't see the branches at all if > they don't want too.
that i wanted to hear. two-three steps instruction for people who want to take a peek or send us updated thailand users manual for trunk two times a month. > The maintainer will take care of the branch merging into "master" upon > request of the developers. But their branch may be periodically merged to > "experimental" if the developer is OK with that. upon request seems quite burden, so the periodical one looks better. > The workflow would be then pretty simple for me: > > 1) I have a great idea and I want to start from "master" > > git branch abdel-great-idea master > > git checkoutabdel-great-idea > > 2) I develop: > > git commit -a > git add xxx > etc. > > 3) I ask the maintainer: my new great idea is mostly functional now, would > you please merge it periodically to "experimental"? > > 4) I develop some more, some other devs might join... > > 5) My feature is ready: I ask the maintainer if he is OK to merge it into > "master" > if yes -> kool, my new great idea will be in next release > if no -> too bad, let's work on it some more... > > Isn't that simple and useful? 1. if you want me to go through this to commit typo in README.localization then i let this file unmaintained. for new spellchecking feature or something of that kind, thats fine. 2. how the stuff goes back to my branch? how many times do i need to resolve merge conflicts more than in svn scenario? thanks for particular examples i waited for them. pavel
