you're supposed to be on vacation - not thinking about git. :) personally, i like this flow as the git history stays pretty clean and easy to follow. i think it would be harder if you upended it with cherry-pick as that changes commit ids between branches.
On Thu, Nov 3, 2016 at 12:00 PM, Dylan Millikin <[email protected]> wrote: > 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. > > > > > > > > >
