Going back to the dual PRs i referenced:

https://github.com/apache/tinkerpop/pull/412
https://github.com/apache/tinkerpop/pull/413

After a few days of review, I noticed this morning that now that they were
ready for merge, they were conflicted. That means some extra steps because
if I had:

git checkout tp31
git merge TINKERPOP-1442

and resolved the conflict as part of the merge then I would create a fresh
merge commit in tp31 which wouldn't be in master (and that would mean that
the next person to serve up a PR from tp31 to master would end up with that
commit hanging in their PR). Since there is a conflict in the PR, I need to
rebase:

git checkout TINKERPOP-1442
git rebase origin/tp31

At this point, I would complete the rebase and maybe test if necessary, and
then:

git push origin TINKERPOP-1442 --force

Now, git rebase has re-written my commit history which is going to hose my
PR to master, so we just need to clean that up:

git checkout TINKERPOP-1442-master
git reset --hard origin/master
git merge TINKERPOP-1442

and again, re-test if necessary and force push, at which point both PRs can
be merged cleanly.  I'll write all this up in the dev docs to serve as a
reference.


On Tue, Sep 13, 2016 at 8:43 PM, Stephen Mallette <spmalle...@gmail.com>
wrote:

> While we haven't started the tp32 branch yet, I thought I'd do the dual PR
> model for a bug fix that i had on tp31 just to see how it would go. So I
> created two branches using the git commands i specified in my last post on
> this thread:
>
> TINKERPOP-1442
> TINKERPOP-1442-master
>
> and created two PRs from them:
>
> https://github.com/apache/tinkerpop/pull/412
> https://github.com/apache/tinkerpop/pull/413
>
> I think it was helpful to "tag" the target branch in the PR description so
> it was easy to figure out just from the PR list which one you were looking
> at. In this case, this was a pretty easy merge situation as there wasn't
> much divergence between the branches. A nice part about this approach is
> that it forces specific testing of the integration of the code to each
> branch, so even though the code changes are pretty much identical, we are
> assured that some other difference elsewhere between the branches doesn't
> create some havoc we didn't know about.
>
> I suppose the VOTE should still occur on both PRs prior to merging. I
> think it will be confusing any other way.
>
> We will need to take care when merging CTR'd work to not inadvertently
> merge commits destined for master on a PR that is under review. I sense
> that is possible with this model. If you CTR to tp32 and attempt a merge to
> master and get "more" commits than just your CTR, you should take a closer
> look at what it is going on. I think this also means that we need to not
> merge the tp32 PR without also being ready to merge the master PR. They
> should both happen in fairly fast succession of one another.
>
> sorry - boring post - thanks for reading.
>
> On Tue, Sep 13, 2016 at 8:08 AM, Stephen Mallette <spmalle...@gmail.com>
> wrote:
>
>> As there have been no objections, we will go with the PR per branch model
>> when we open the tp32 branch this coming weekend. The flow is pretty
>> simple. Let's say you have work for tp32:
>>
>> 1. git checkout -b <TINKERPOP-1234> tp32
>> 2. do a bunch of stuff and commit in there
>> 3. git checkout -b <TINKERPOP1234-master> master
>> 4. git merge TINKERPOP-1234
>>
>> That produces two branches, one for tp32 and one for master, from which
>> you can formulate the PRs in GitHub. One issue I thought of this morning
>> was what to do in the case of CTRs where we commit directly to tp32. In
>> those cases, the committer should immediately merge to master as we
>> normally do:
>>
>> git checkout master
>> git merge tp32
>>
>> Presumably, CTR'd work will be a single small commit that is easy to
>> merge. I think we should try to avoid cherry-pick in this model as it
>> re-writes history (i.e. new hash generated for the cherry-picked commit).
>> If we need a commit to stay in tp31 there are ways to do the merge without
>> bringing that specific commit forward. Hope that all makes sense to
>> everyone. I'll probably add something to the dev docs about this model for
>> when we get stated with tp32 next week.
>>
>>
>> On Thu, Sep 8, 2016 at 3:47 PM, Daniel Kuppitz <m...@gremlin.guru> wrote:
>>
>>> Sounds good to me. It won't necessarily mean much more work, since I
>>> assume
>>> that most branches won't have any merge conflicts.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On Thu, Sep 8, 2016 at 6:36 PM, Stephen Mallette <spmalle...@gmail.com>
>>> wrote:
>>>
>>> > I think 3.3.0 will be a "big" release with many breaking changes as we
>>> > remove deprecation, upgrade certain dependencies, and make other
>>> usability
>>> > improvements. This won't be a release we want to rush as it affords us
>>> an
>>> > opportunity to make a number of things a lot better. I believe that
>>> we'd
>>> > discussed having 3.3.0 as a release for the end of 2016, but the more I
>>> > think about it, the more I wonder if that's enough time.
>>> >
>>> > Anyway, I think that if we hope to get a 3.3.0 out by end of 2016 or
>>> early
>>> > 2017, we will need to get started sooner than later. That of course,
>>> would
>>> > lead us to our branching model in git and how we will want to approach
>>> > that.
>>> >
>>> > Right now, things are pretty simple. We maintain master and tp31
>>> branches
>>> > and tp31 merges one-way to master. If we want to start work on 3.3.0,
>>> then
>>> > I think we should begin a tp32 branch for the 3.2.x line of code and
>>> make
>>> > master be 3.3.x. Of course, that complicates our workflow slightly
>>> because
>>> > tp31 will need to merge to tp32 and then tp32 to master. While tp31
>>> > development has ceased with the exception of bug fixes, I already find
>>> > divergence between tp31 and master as things stand today and that will
>>> only
>>> > get worse as we make breaking change to master. The point is that it
>>> may be
>>> > burdensome to merge tp32 to master at times for those other than the
>>> > original author of the work being merged.
>>> >
>>> > We may find that we may need a multi-pull request model to cleanly deal
>>> > with conflicts inherent to the merge. In other words, a change to tp31
>>> > would mean a separate pull request to tp31, tp32 and master (as
>>> opposed to
>>> > one pull request to tp31 with a merge at some later time to tp32 and
>>> then
>>> > at some later time tp32 to master). For a change to tp32 you would
>>> just do
>>> > a PR to tp32 and a PR to master. That would be the safest way to deal
>>> with
>>> > conflicts and not have any surprises for some poor sap doing a blind
>>> merge
>>> > from one of our release branches down the line.
>>> >
>>> > Any thoughts on any of this?
>>> >
>>>
>>
>>
>

Reply via email to