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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>> 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? >>> > >>> >> >> >
