[Releasing] [Development] Qt 4.8.1 open source release date approaching..

[shane.kearns at accenture.com]

> On Fri, Mar 09, 2012 at 07:16:24PM +0000, ext
> shane.kearns at accenture.com 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