MIME-Version: 1.0
Sender: five9a2@gmail.com
In-Reply-To: <87r568yhq5.fsf@zancas.localnet>
References: <87y60hn0mg.fsf@zancas.localnet> <87r568yhq5.fsf@zancas.localnet>
Date: Sat, 2 Jul 2011 15:23:02 -0500
Message-ID: <BANLkTik4hYYHpe_igt-Vf6t8e+_bVz6p+g@mail.gmail.com>
Subject: Re: branchs and tags and merges oh my!
From: Jed Brown <jed@59A2.org>
To: David Bremner <david@tethera.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org
Precedence: list

On Sat, Jul 2, 2011 at 07:44, David Bremner <david@tethera.net> wrote:
>
> A third strategy is "git checkout master && git merge -s ours 0.6".
> Then history will look like this:
>
> =C2=A0freeze
> --.-------------.----- master
> =C2=A0 \ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /
> =C2=A0 =C2=A0-----------
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 release
>
> As long as every patch on the release branch is already on master, -s
> ours (which throws away all the changes from the side branch) is
> reasonable.

Remind me of why bugfix patches can't (usually) be applied to the
release branch first, then merged into master? When the patch is
(accidentally or otherwise) applied to master first, then I think you
have no choice but to have it appear twice in the history, once in
master and once in release, and using the model you describe above
seems the most sensible way to do that.