Re: State of the repository conversion

[Steinar Bang]

>>>>> Stefan <address@hidden>:

> Not sure why this matters: we don't cherry pick from the maintenance
> branch.  Instead we merge the development branch.  And we sometimes
> cherry pick fixes from the development branch into the maintenance
> branch (which makes the subsequent merge a bit more delicate, since we
> want to avoid applying that change twice).

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

(The latter command will apply the changes from the merge, and then stop
before committing)

Then I look at the changes in magit, and ideally there should be no
diffs, because I have done the same thing earlier in the lifetime of the
release branch, and have told git to drop irrelevant changes from the
release branch.

The way to tell git to drop the merge results and instead pick the
version from master, is to insert the master branch's version of the
file before committing, eg.:
 git checkout origin/master version.txt

(this picks the master branch's version of the, er..., version file.
"origin/master" means the version of the master branch that has been
pushed to the remote git repository named "origin")
name of the first 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).

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.

And most of the time the merge will be conflict free and correct.

But I always do
 git commit --no-ff --no-commit
in these cases, and look at the diffs resulting from the merge in magit.