Jeff King <peff@xxxxxxxx> writes: > On Tue, Apr 21, 2009 at 12:24:26PM -0700, skillzero@xxxxxxxxx wrote: > >> We have a "future" branch for new development. I wanted to add a new >> feature so I branched from "future" to create a branch named >> "feature". I completed the work, but now they've decided they need >> that on two older branches. It looks like this: >> [...] >> I've read I should have started from the oldest common denominator >> branch that I might ever want, but at the time I created the branch, > > Right. Junio branches all topics in git from "master", but then merges > promising ones into "next". When the topic is ready for master, he can > then just merge the topic branch, pulling in that topic but not the rest > of next. No, I don't. I often branch from somewhere older than 'master', often tip from 'maint' sometimes even older. And that is not necessarily because I am better than other people in planning ahead. There are branches that forked from older series (like 1.6.0.X) that are merged to next and then master, without ever getting merged to produce 1.6.0.(X+1). > Yep. Advanced planning is not always possible. :) > >> What's the best way to merge changes on the "feature" branch into the >> 1.1 and 1.2 branches? If I try to checkout 1.1 then 'git merge > > If it is just one or two commits, you probably just want to "git > cherry-pick" them onto your older branches. I would suggest against it. Just like you did not manage to plan in advance for these two patches to fork from older branches, you will regret later that these two were still full of bugs and need to be fixed up with more patches on top. Even if they are only a few right now, keeping a cleaned up series that applies to the oldest would be easier to manage in the long run. I.e., rebase feature onto somewhere older (like 1.1): git rebase --onto v1.1 feature~2 feature then let q&a people merge that to v1.1 and v1.2, while keeping the tip of the feature still open. You will queue further fix-ups on that branch and tell q&a people to merge again to get the fixed to the feature. -- 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