You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2016/11/03 14:17:21 UTC
state of git
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.
Re: state of git
Posted by Stephen Mallette <sp...@gmail.com>.
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 <dy...@gmail.com>
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 <sp...@gmail.com>
> 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 <ok...@gmail.com>
> > 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 <sp...@gmail.com>
> > > 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.
> > >
> > >
> >
>
Re: state of git
Posted by Dylan Millikin <dy...@gmail.com>.
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 <sp...@gmail.com>
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 <ok...@gmail.com>
> 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 <sp...@gmail.com>
> > 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.
> >
> >
>
Re: state of git
Posted by Stephen Mallette <sp...@gmail.com>.
...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 <ok...@gmail.com>
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 <sp...@gmail.com>
> 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.
>
>
Re: state of git
Posted by Marko Rodriguez <ok...@gmail.com>.
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 <sp...@gmail.com> 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.