couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirkjan Ochtman <dirk...@ochtman.nl>
Subject Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Date Wed, 22 May 2013 16:38:05 GMT
On Wed, May 22, 2013 at 3:29 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Tue, May 21, 2013 at 6:22 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
>> Here's a diagram. In this I show a feature branch landing on master
>> and a backport of it landing on 1.3.x, but if we follow the procedure
>> I'm suggesting I think it can even be easy to keep track of
>> cherry-picked backports.
>>
>> https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY
>>
>> The fancy things here are
>>   * merge-base: to find the common ancestor

As in, the common ancestor on a release branch? Because you don't want
to use the old feature branch head as ancestor, but rather the branch
point where the release branch deviated from master?

>>   * --no-commit: so NEWS and CHANGES can be reconciled atomically with
>> respect to what the git logs will say is unmerged

Not sure why you'd need that here.

>>   * -Xours: so that we can merge release branches to master *without*
>> code changes, just to mark a point in history so that a future
>> merge-base will only show us what hasn't made it into NEWS and CHANGES
>> since we last did this.
>
> (snip)
>
> But maybe I'm overthinking it since one alternative is to just update
> NEWS and CHANGES whenever we make commits. However, I think if we just
> merge releases to master whenever we make a backport or a release then
> it will be a very quick and painless process to update NEWS and
> CHANGES when it comes time for 1.4.x.

Yeah, I don't think we actually need the "ours" merge strategy here.

I do think we should try merging from release branch to master some
time soon (e.g. after the next feature release).

Cheers,

Dirkjan

Mime
View raw message