With multiple branches set up as they are here, wouldn't it help to move to a more classical workflow, that is to push to master and then backport/cherry pick downwards? This comes with it's own set of implications but thought I would ask.
On Thu, Nov 3, 2016 at 9:19 PM, Stephen Mallette <[email protected]> wrote: > ...and all is right with the world again... > > In case others are interested, the trouble here is that if I had merged my > tp32 to master with my change from tp31, then I would have brought Marko's > changes from tp32 to master. I wouldn't want to do that because I wouldn't > have been sure that Marko wanted that to happen. For all I knew he could > have been trying to fix a problem on master with his merge from tp32 and my > merging could have broken the branch. Ideally, you should only push your > own changes, so if you ever merge tp32 to master (for example) and there > are commits present that are not ones you did, you probably need to stop > and figure out what's going on. > > Here's how I noticed it: > > $ git checkout master > Switched to branch 'master' > $ git merge tp32 > Auto-merging CHANGELOG.asciidoc > Merge made by the 'recursive' strategy. > CHANGELOG.asciidoc > | 2 ++ > docs/src/dev/provider/index.asciidoc > | 2 +- > docs/src/upgrade/release-3.1.x-incubating.asciidoc > | 18 > ++++++++++++++++++ > gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/ > process/traversal/strategy/decoration/SubgraphStrategy.java > | 16 +++------------- > gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/ > process/traversal/strategy/optimization/IncidentToAdjacentStrategy.java > | 11 ++++++++++- > gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/ > process/traversal/util/TraversalHelper.java > | 21 +++++++++++++++++++++ > gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/ > driver/Connection.java > | 2 +- > gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/ > server/op/session/SessionOpProcessor.java > | 5 +++++ > 8 files changed, 61 insertions(+), 16 deletions(-) > > WHOA - I knew that I didn't touch SubgraphStrategy or > IncidentToAdjacentStrategy, so that looked fishy. So I get rid of all that > with: > > $ git reset --hard origin/master > HEAD is now at ea085f8 Merge branch 'tp32' > > and reset my local master branch back to what it was prior to the merge > (i.e what is at origin/master). After I emailed the list and ping'd marko > who promptly did the merge to master I did: > > $ git fetch origin > remote: Counting objects: 123, done. > remote: Compressing objects: 100% (8/8), done. > remote: Total 13 (delta 4), reused 0 (delta 0) > Unpacking objects: 100% (13/13), done. > From https://git-wip-us.apache.org/repos/asf/tinkerpop > ea085f8..eaad5a9 master -> origin/master > $ git rebase origin/master > First, rewinding head to replay your work on top of it... > Fast-forwarded master to origin/master. > $ git merge tp32 > Auto-merging CHANGELOG.asciidoc > Merge made by the 'recursive' strategy. > CHANGELOG.asciidoc > | 1 + > docs/src/dev/provider/index.asciidoc > | 2 +- > docs/src/upgrade/release-3.1.x-incubating.asciidoc > | 18 ++++++++++++++++++ > gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/ > driver/Connection.java > | 2 +- > gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/ > server/op/session/SessionOpProcessor.java > | 5 +++++ > 5 files changed, 26 insertions(+), 2 deletions(-) > > So i applied marko's changes to master with git rebase, then merged my > local tp32 to master and now those two changes I wasn't responsible for are > gone. Then it's just a push doing master first and then tp32 (newest > release to oldest release order): > > $ git push origin master > Counting objects: 213, done. > Delta compression using up to 4 threads. > Compressing objects: 100% (32/32), done. > Writing objects: 100% (48/48), 3.44 KiB | 0 bytes/s, done. > Total 48 (delta 25), reused 0 (delta 0) > remote: tinkerpop git commit: Merge branch 'tp32' > remote: tinkerpop git commit: Merge branch 'tp31' into tp32 > remote: tinkerpop git commit: TINKERPOP-1544 Return confirmation on session > close > gTo https://git-wip-us.apache.org/repos/asf/tinkerpop.git/ > eaad5a9..3f57dfe master -> master > $ git push origin tp32 > Total 0 (delta 0), reused 0 (delta 0) > remote: tinkerpop git commit: Merge branch 'tp31' into tp32 > remote: tinkerpop git commit: TINKERPOP-1544 Return confirmation on session > close > To https://git-wip-us.apache.org/repos/asf/tinkerpop.git/ > b4d0ef9..9e284f7 tp32 -> tp32 > > All good! > > > On Thu, Nov 3, 2016 at 10:31 AM, Marko Rodriguez <[email protected]> > wrote: > > > I don’t understand git. > > > > I don’t understand rebasing. > > > > I don’t understand what love is. > > > > Marko. > > > > http://markorodriguez.com > > > > > > > > > On Nov 3, 2016, at 8:17 AM, Stephen Mallette <[email protected]> > > wrote: > > > > > > just a quick note - the git repo is in a weird state atm. I > accidentally > > > pushed a change to tp31 thinking i would then instantly merge to > > > tp32/master, but I think marko has a change on tp32 that he hasn't > merged > > > to master yet (so he basically did the same thing i did and pushed too > > > early). > > > > > > So right now, merging is sorta locked up behind marko's merge to master > > and > > > I need to step away for a few minutes leaving git kinda weird. > > > > > > Typically, the flow for a merge should involve getting the entire > > situation > > > clear in all branches first before pushing. So if your change is on > tp31, > > > then merge it locally to tp32 and then merge tp32 to master locally - > > > resolve conflicts and test as needed. Then when all good, push in > reverse > > > order to each of the branches. Using that same example, start with > master > > > and then go to tp32 and then tp31. I think that should limit weirdness > if > > > someone is pulling while you are pushing. The same logic would apply if > > you > > > produced multiple pull requests for the same change which may become > the > > > norm at some point in the future. > > > > > > Anyway, until we sort out the merge backup, please refrain from merging > > > between branches. I'll be back online shortly. > > > > >
