> On Fri, Mar 09, 2012 at 07:16:24PM +0000, ext
> [email protected] wrote:
> >
> > (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix
> > \
> > fix(rc2)-fix(v4.8.1)
> >
> this is no option, because it "loses" the tag from the history.
> "traditionally" we have merged back the release branch to the
> maintenance branch (and thus to master), which means that we have all
> those cherry-picks twice in the history. try to read *that*.
> therefore the only clean options are either a) just don't create a
> branch or b) if you create a branch, then apply any fixes which are
> supposed to be in it *only* to that branch, so it can be cleanly
> forward-merged.
>
The full picture including the merge back would look like:
(rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix-o-o-o-M
\ /
fix(rc2)-fix(v4.8.1)-----------------.
The tag has to be on the branch (if there is a branch), otherwise "git checkout
v4.8.1" doesn't give the same thing as the release tarball.
Tools that show the history including branches (e.g. gitk) would give a picture
like what's above, "git log" will show the cherry picks twice in the history.
The history is unreadable for v4.8.0 because of the 7 parallel staging
branches, but displaying two parallel branches (4.8 and 4.8.1) should be sane
and readable.
I believe that "git log v4.8.1.." includes the commits which came in with the
merge (anything on 4.8 but not on 4.8.1 branch)
________________________________
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored by
our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
______________________________________________________________________________________
www.accenture.com
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
