From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: skillzero@gmail.com, git@vger.kernel.org
Subject: Re: How to merge from newer branch to older branches?
Date: Tue, 21 Apr 2009 22:13:23 -0700 [thread overview]
Message-ID: <7vmya946fg.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 20090421193615.GB7832@coredump.intra.peff.net
Jeff King <peff@peff.net> writes:
> On Tue, Apr 21, 2009 at 12:24:26PM -0700, skillzero@gmail.com 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.
next prev parent reply other threads:[~2009-04-22 5:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-21 19:24 How to merge from newer branch to older branches? skillzero
2009-04-21 19:36 ` Jeff King
2009-04-22 5:13 ` Junio C Hamano [this message]
2009-04-22 13:34 ` Jeff King
2009-04-22 17:44 ` skillzero
2009-04-22 20:15 ` Jeff King
2009-04-22 21:01 ` skillzero
2009-04-22 21:17 ` Jeff King
2009-04-22 4:46 ` John M. Dlugosz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vmya946fg.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=skillzero@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).