git workflow suggestion for Bazel repo: avoid cherry-pick when prepping a new release

Description of the problem / feature request / question:

It seems that that Bazel team’s current git workflow is: When a new release is almost ready, make a branch for that release; then, as necessary, cherry-pick last-minute fixes from master into that branch, until the release is done.

My org has a fork of Bazel with some changes of our own, and the cherry-picking makes it very hard for us to move from one version of Bazel to the next, because we can’t git merge. (At least, I think it’s the cherry-picks that are causing all the conflicts.)

I think that it might work better to turn your workflow around: When you have a change that needs to be in the upcoming release, first commit it to the release branch, and then merge (not cherry-pick) the release branch into master.

[mmorearty]

Here’s a concrete example of the sort of merge conflicts that I’ve been getting. Try this — start at version 0.4.5 and then try to “merge” to get up to version 0.5.0, with no custom changes at all:

$ git checkout 0.4.5
$ git checkout -b mybranch
$ git merge 0.5.0

That’s a pretty simple series of commands, and I would think it would work; yet it results in merge conflicts in 36 files.

If you take a look at the conflict in CHANGELOG.md, you’ll see that git can’t resolve the “conflict”, because the 0.4.5 version has the description of 0.4.5; the 0.5.0 version has that plus the description of 0.5.0; and the merge-base has neither. If git merge was being used instead of cherry-picking, git would have been able to figure out what to do.

I did eventually figure out a workaround: I git merge twice. First, I git merge only up to the commit on master that corresponds directly to the corresponding head of 0.4.5; then I git merge again the rest of the way. That way, most of the changes that git sees in the first git merge are identical on both sides. Like this:

$ git checkout 0.4.5
$ git checkout -b mybranch
# merge only up to the master commit that corresponds to the head of 0.4.5:
$ git merge 8d635fc57
# resolve just one conflict. then:
$ git merge 0.5.0

[hlopko]

I guess we can close this issue now, feel free to shout at me otherwise 😃