Theodore Tso <tytso@xxxxxxx> wrote: > On Mon, Oct 22, 2007 at 06:29:59PM -0700, Junio C Hamano wrote: > > Well, the policy is never to commit directly on top of next > > (iow, only merge other topics and nothing else). Otherwise it > > becomes hard to allow individual topics graduate to 'master' > > independently. > > I see. So if it's non-trivial enough that you want it to "cook" in > next for a cycle, you'll create a topic branch for it (based off of > 'master'), and then force a merge into 'next'? Yes. Because 'next' always has commits in it that never appear in 'master'. So any topic forked from master must merge into next. It can't be a fast-forward. No forced merging required. Of course this isn't true for a new project. That first topic that forked from master to *create* next will be a fast-forward as it creates next. But that's no big deal. The second topic will merge into next, and that first topic can still be merged back into master without merging next (or the second topic). I was also doing the same thing Junio already explained to manage next and pu while he was away. Except I shortcut his: git checkout pu git reset --hard next as: git branch -f pu next git checkout pu as I'm was usually already sitting on next. This saved my poor little laptop from a second of IO chugging as it slewed around between the two versions. There were no files to update as it switched from next to pu, and pu was already setup for merging the proposed topics. :-) -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
