Re: State of the repository conversion

[Florian Weimer]

* Steinar Bang:

> What I do, after cherry picking a fix from the master HEAD back into a
> release branch (named "release-branch" in the below commands) is
> immediately do a:
>  git checkout master
>  git merge --no-ff --no-commit release-branch

> After I am satisfied that the merge results contains no unexpected
> changes with master, I do a:
>  git commit
> to complete the merge (or just do a `c' in magit).

This complicates the history of the master branch.  It is not clear if
it adds any useful information, especially if there is no expectation
of ever doing development on release branches and merge this
development back to the master branch later.

> Whenever I am doing a bugfix, I _try_ to start a local branch in the
> earliest branch where the fix is relevant, and do the fix there.  Then,
> instead of cherry picking, I can just merge the fix into the newer
> branches that should have the same fix.

Tool support is generally better if you make the change in the oldest
supported release branch and merge that forward, but in practice, this
doesn't work that well.  Often, you don't know for sure what the
oldest release branch that needs the change is.  And from a general
engineering point of view, it is better to develop the best fix
possible on the master branch, test it, and then start backporting it,
taking shortcuts as necessary.  If you do it in the other order, you
tend to end up with a suboptimal change in the master branch.  And the
development history becomes really, really complicated, too.