couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: [REQUEST] Merge changes for CouchDB 1.3.1
Date Fri, 17 May 2013 20:52:11 GMT
On Fri, May 17, 2013 at 12:55 PM, Noah Slater <> wrote:
> Not sure, Randal. Dave was asking similar things on IRC today.
> We need to drive that to conclusion. (Unfortunately, I'm not your man for
> that. Git is not my wheelhouse.)
> On 17 May 2013 19:59, Randall Leeds <> wrote:
>> Where are we with merge procedure? What's the workflow we want to see
>> for master -> 1.3.1?

I just asked this as a question to me G+ coder circles. If you're
among these people you should be able to see it. If not, I'm repasting
it below.

tl;dr -- I think if all fixes land via a merge we can see which things
haven't been backported with one git command. In cases where a
backport is not straightforward enough to just merge to the release
branch then making a branch off the fix branch to massage the change
for backport should ensure that, as far as git can tell, the original
fix branch "made it" into the release branch and the master branch.
This requires enforcing that all bug fixes land as merge commits. I
don't see another, less onerous, way to preserve the history required
for at-a-glance checking of backport status.


What git workflow tips do people have for dealing with multiple
supported branches. When you have a bugfix that should land in
multiple places do you always do it as a merge or cherry-pick to
backport? When backporting requires changes vis-a-vis the original fix
that go beyond what autoresolves in a merge do you create a backport

I'm thinking something like:
- All fixes (as opposed to features, which are not candidates for
backporting) should go in branches.
- All such branches should land with --no-ff
- Backports should have branches named
For example, 1012-fix-some-bug and 1021-fix-some-bug-backport-1.3.x.

The thinking goes as follows. If every fix has a merge commit on
master and every backport merged to X.Y.Z release branch is either a
merge commit pointing at the same fix or a backport branch descending
therefrom then `git log --merges X.Y.Z..master` should show all the
fixes that haven't been backported.

Is that correct?


View raw message