Re: Unexpected/unexplained difference between git pull --rebase and git rebase
On Tue, Mar 03, 2015 at 03:54:05PM -0800, Mike Botsko wrote:
Thanks, that clarifies a lot.
I only have two follow-up questions:
In your branch example, how does git determine that C/D have been
rewritten and need to be replaced with their current versions
existing upstream? In this scenario I've encountered, the commit hash
and the patch ID of those commits changed because the contents of the
patches had to be modified slightly due to merge conflicts which
occurred when the upstream branch was rebased.
It uses the reflog. There's some discussion in git-merge-base(1) [0],
although IIRC it steers away from being too explicit in case anyone
comes up with a way to make it more intelligent in the future.
Note that this means it will only work if you are performing the rebase
in the same repository as you originally created the branch, since in
other repositories the original branch point may not appear in the
reflog of the upstream.
[0] http://git-scm.com/docs/git-merge-base#_discussion_on_fork_point_mode
Also, you mentioned not building off of upstream branches which might
be rewritten. We generally try to avoid this but I don't see any
alternative with the way we do things.
upstream/master - An always-clean copy of what's fully approved and live
upstreamfeature-A
upstreamfeature-B, etc - Feature branches designed to organized
long-term new feature work
Individual developers will then create local development branches
based on those feature branches. If three people are responsible for
tasks for feature-A, they'll create development branches for each
task, do their work, and(via github enterprise) submit a pull request
so we can properly review their work, test it, etc.
The problem I have today stems from situations where a feature branch
has been merged with master. If feature-B is merged with master, and
someone rebases feature-A, there may be merge conflicts. If they fix
the conflicts, that may alter the commit history of the feature
branch, which then impacts all branches developers have based on it.
Part of me feels like we should be able to never rebase feature
branches, they should exist outside of new work merged to master.
However, it's much easier to resolve merge conflicts in small doses,
and we're in a much better position to know that we're fully updated
and can catch other problems early.
Is there a better way to do this, so that we never risk rewriting the
middle tier?
Having two tiers of feature branches seems a bit weird to me (although I
do know of another group that does something similar).
Perhaps a throwaway integration branch would help, which will allow you
to let git-rerere(1) remember resolutions to merge conflicts. The idea
is that you periodically (say once a day or every few days) do something
like this:
$ git checkout integration
$ git reset --keep master
$ git merge feature-A
$ git merge feature-B
...
Then you can test the features together and get an early view of any
conflicts that might hit when you merge them to master.
shameless-plug
I wrote a tool to help manage integration branches [1].
[1] http://johnkeeping.github.io/git-integration/
/shameless-plug
There's quite a lot of discussion on branch management in
git-workflows(7).
On Tue, Mar 3, 2015 at 3:40 PM, John Keeping j...@keeping.me.uk wrote:
On Tue, Mar 03, 2015 at 03:20:48PM -0800, Mike Botsko wrote:
Maybe I'm lacking the distinction regarding what I'm being specific about.
In both examples, I'm asking it specifically to rebase in changes from
the remote upstream and a named branch at that location. I'm giving
git the same information, it's just interpreting it differently - and
I'm not understanding why.
Not quite. If you say:
git rebase $sha1
then you're telling git-rebase to apply the commits $sha1..HEAD onto
$sha1.
If you say:
git rebase
then it will be re-written as:
git rebase --fork-point @{upstream}
in which case Git will apply more complicated logic so that you can
recover from the case where @{upstream} has been re-written.
Consider the following scenario:
F branch
/
C -- D master@{1}
/
A -- B -- C' -- D' -- E master
where C' and D' are rewritten versions of C and D.
In this case, imagine you are at F on branch, git rebase master will
replace C, D and F onto E because you have explicitly selected to replay
master..branch onto master.
git rebase will apply the fork-point logic and realise that D is a
previous version of master, so it will only replay F onto E.
In general if you just want to rebase onto your upstream it is simpler
to just call git rebase which will do the right thing; it's also
shorter to type ;-)
My local branch would have been created from the
Unexpected/unexplained difference between git pull --rebase and git rebase
Hello, I'm seeing unexpected behavior between git pull --rebase and git rebase commands, which are supposed to be (and always described as) synonymous: git pull --rebase upstream our-branch-name and git fetch upstream git rebase upstream/our-branch-name We have a situation where the upstream/our-branch-name was rebased, to incorporate changes from master. Somehow, the person who did the rebase discarded a merge commit: 634b622 Sue Merge pull request #254 from bob/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments became: c1452be Sue [B-07290] Order Parts Ship To/Comments A developer who had a local branch tried to rebase their work (a single commit on top of that feature branch). At the moment, his now-out-of-date branch looks like this: 92b2194 Rick B-07241 634b622 Sue Merge pull request #254 from dboyle/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments I've done some debugging, and the above git pull command generates the following and sends it to eval(): git-rebase --onto c1452be62cf271a25d3d74cc63cd67eca51a127d 634b622870a1016e717067281c7739b1fe08e08d This process works perfectly. The old commits are discarded and his branch now correctly reflects upstream/our-branch-name, with his single new commit at the top. However, if he runs the git rebase command above, several of the commits that have changed hashes (they've also changed patch id slightly, because during the rebase someone fixed a merge conflict) are treated as new work, and git tries to re-apply them and we get tons of merge conflicts. The git rebase command above is trying to rebase onto: revisions = c1452be62cf271a25d3d74cc63cd67eca51a127d..92b2194e3adc29eb3fadd93ddded0ed34513d587 These two features should work the same, yet one is choosing a different commit hash than the other. If this is not a bug, I can't find anyone who can explain what's happening. I'm using git 2.2.1 on mac, but other people on our team have a variety of older versions and we're all seeing the same result. Thanks! -- Mike Botsko Lead Dev @ Helion3 Ph: 1-(503)-897-0155 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexpected/unexplained difference between git pull --rebase and git rebase
On Tue, Mar 03, 2015 at 01:31:39PM -0800, Mike Botsko wrote: I'm using git 2.2.1 on Mac OS X Yosemite. I just tried the git rebase with --fork-point added, and it works properly: $ git rebase upstream/our-branch-name --fork-point First, rewinding head to replay your work on top of it... Applying: B-07241 While discussing with someone else, he mentioned poking about a bit more, git rebase began defaulting to --fork-point in git 1.9, so one might expect it to be there in that version - but we figured it might be related to https://github.com/git/git/commit/1e0dacdbdb751caa5936b6d1510f5e8db4d1ed5f. I upgraded my version of git, but it wasn't fixed. I assume he was incorrect in that git rebase uses --fork-point by default? git-rebase assumes that if you give an explicit upstream then you want precisely what you asked for. From git-rebase(1): If either upstream or --root is given on the command line, then the default is `--no-fork-point`, otherwise the default is `--fork-point`. On Tue, Mar 3, 2015 at 1:09 PM, John Keeping j...@keeping.me.uk wrote: On Tue, Mar 03, 2015 at 12:39:31PM -0800, Mike Botsko wrote: I'm seeing unexpected behavior between git pull --rebase and git rebase commands, which are supposed to be (and always described as) synonymous: git pull --rebase upstream our-branch-name and git fetch upstream git rebase upstream/our-branch-name We have a situation where the upstream/our-branch-name was rebased, to incorporate changes from master. Somehow, the person who did the rebase discarded a merge commit: 634b622 Sue Merge pull request #254 from bob/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments became: c1452be Sue [B-07290] Order Parts Ship To/Comments A developer who had a local branch tried to rebase their work (a single commit on top of that feature branch). At the moment, his now-out-of-date branch looks like this: 92b2194 Rick B-07241 634b622 Sue Merge pull request #254 from dboyle/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments I've done some debugging, and the above git pull command generates the following and sends it to eval(): git-rebase --onto c1452be62cf271a25d3d74cc63cd67eca51a127d 634b622870a1016e717067281c7739b1fe08e08d This process works perfectly. The old commits are discarded and his branch now correctly reflects upstream/our-branch-name, with his single new commit at the top. However, if he runs the git rebase command above, several of the commits that have changed hashes (they've also changed patch id slightly, because during the rebase someone fixed a merge conflict) are treated as new work, and git tries to re-apply them and we get tons of merge conflicts. The git rebase command above is trying to rebase onto: revisions = c1452be62cf271a25d3d74cc63cd67eca51a127d..92b2194e3adc29eb3fadd93ddded0ed34513d587 These two features should work the same, yet one is choosing a different commit hash than the other. If this is not a bug, I can't find anyone who can explain what's happening. I'm using git 2.2.1 on mac, but other people on our team have a variety of older versions and we're all seeing the same result. What version of Git are you using? Does it work if you add the `--fork-point` argument to git-rebase? If so, does it do the same if you just do git rebase with no arguments (see the documentation of `--fork-point` in git-rebase(1) for details of this)? -- Mike Botsko Lead Dev @ Helion3 Ph: 1-(503)-897-0155 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexpected/unexplained difference between git pull --rebase and git rebase
On Tue, Mar 03, 2015 at 12:39:31PM -0800, Mike Botsko wrote: I'm seeing unexpected behavior between git pull --rebase and git rebase commands, which are supposed to be (and always described as) synonymous: git pull --rebase upstream our-branch-name and git fetch upstream git rebase upstream/our-branch-name We have a situation where the upstream/our-branch-name was rebased, to incorporate changes from master. Somehow, the person who did the rebase discarded a merge commit: 634b622 Sue Merge pull request #254 from bob/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments became: c1452be Sue [B-07290] Order Parts Ship To/Comments A developer who had a local branch tried to rebase their work (a single commit on top of that feature branch). At the moment, his now-out-of-date branch looks like this: 92b2194 Rick B-07241 634b622 Sue Merge pull request #254 from dboyle/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments I've done some debugging, and the above git pull command generates the following and sends it to eval(): git-rebase --onto c1452be62cf271a25d3d74cc63cd67eca51a127d 634b622870a1016e717067281c7739b1fe08e08d This process works perfectly. The old commits are discarded and his branch now correctly reflects upstream/our-branch-name, with his single new commit at the top. However, if he runs the git rebase command above, several of the commits that have changed hashes (they've also changed patch id slightly, because during the rebase someone fixed a merge conflict) are treated as new work, and git tries to re-apply them and we get tons of merge conflicts. The git rebase command above is trying to rebase onto: revisions = c1452be62cf271a25d3d74cc63cd67eca51a127d..92b2194e3adc29eb3fadd93ddded0ed34513d587 These two features should work the same, yet one is choosing a different commit hash than the other. If this is not a bug, I can't find anyone who can explain what's happening. I'm using git 2.2.1 on mac, but other people on our team have a variety of older versions and we're all seeing the same result. What version of Git are you using? Does it work if you add the `--fork-point` argument to git-rebase? If so, does it do the same if you just do git rebase with no arguments (see the documentation of `--fork-point` in git-rebase(1) for details of this)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexpected/unexplained difference between git pull --rebase and git rebase
I'm using git 2.2.1 on Mac OS X Yosemite. I just tried the git rebase with --fork-point added, and it works properly: $ git rebase upstream/our-branch-name --fork-point First, rewinding head to replay your work on top of it... Applying: B-07241 While discussing with someone else, he mentioned poking about a bit more, git rebase began defaulting to --fork-point in git 1.9, so one might expect it to be there in that version - but we figured it might be related to https://github.com/git/git/commit/1e0dacdbdb751caa5936b6d1510f5e8db4d1ed5f. I upgraded my version of git, but it wasn't fixed. I assume he was incorrect in that git rebase uses --fork-point by default? On Tue, Mar 3, 2015 at 1:09 PM, John Keeping j...@keeping.me.uk wrote: On Tue, Mar 03, 2015 at 12:39:31PM -0800, Mike Botsko wrote: I'm seeing unexpected behavior between git pull --rebase and git rebase commands, which are supposed to be (and always described as) synonymous: git pull --rebase upstream our-branch-name and git fetch upstream git rebase upstream/our-branch-name We have a situation where the upstream/our-branch-name was rebased, to incorporate changes from master. Somehow, the person who did the rebase discarded a merge commit: 634b622 Sue Merge pull request #254 from bob/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments became: c1452be Sue [B-07290] Order Parts Ship To/Comments A developer who had a local branch tried to rebase their work (a single commit on top of that feature branch). At the moment, his now-out-of-date branch looks like this: 92b2194 Rick B-07241 634b622 Sue Merge pull request #254 from dboyle/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments I've done some debugging, and the above git pull command generates the following and sends it to eval(): git-rebase --onto c1452be62cf271a25d3d74cc63cd67eca51a127d 634b622870a1016e717067281c7739b1fe08e08d This process works perfectly. The old commits are discarded and his branch now correctly reflects upstream/our-branch-name, with his single new commit at the top. However, if he runs the git rebase command above, several of the commits that have changed hashes (they've also changed patch id slightly, because during the rebase someone fixed a merge conflict) are treated as new work, and git tries to re-apply them and we get tons of merge conflicts. The git rebase command above is trying to rebase onto: revisions = c1452be62cf271a25d3d74cc63cd67eca51a127d..92b2194e3adc29eb3fadd93ddded0ed34513d587 These two features should work the same, yet one is choosing a different commit hash than the other. If this is not a bug, I can't find anyone who can explain what's happening. I'm using git 2.2.1 on mac, but other people on our team have a variety of older versions and we're all seeing the same result. What version of Git are you using? Does it work if you add the `--fork-point` argument to git-rebase? If so, does it do the same if you just do git rebase with no arguments (see the documentation of `--fork-point` in git-rebase(1) for details of this)? -- Mike Botsko Lead Dev @ Helion3 Ph: 1-(503)-897-0155 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexpected/unexplained difference between git pull --rebase and git rebase
John Keeping j...@keeping.me.uk writes: git-rebase assumes that if you give an explicit upstream then you want precisely what you asked for. From git-rebase(1): If either upstream or --root is given on the command line, then the default is `--no-fork-point`, otherwise the default is `--fork-point`. Correct. You ask it to rebase the history without guessing by being explicit; the command guesses when you are not explicit and being lazy ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexpected/unexplained difference between git pull --rebase and git rebase
Thanks, that clarifies a lot.
I only have two follow-up questions:
In your branch example, how does git determine that C/D have been
rewritten and need to be replaced with their current versions
existing upstream? In this scenario I've encountered, the commit hash
and the patch ID of those commits changed because the contents of the
patches had to be modified slightly due to merge conflicts which
occurred when the upstream branch was rebased.
Also, you mentioned not building off of upstream branches which might
be rewritten. We generally try to avoid this but I don't see any
alternative with the way we do things.
upstream/master - An always-clean copy of what's fully approved and live
upstreamfeature-A
upstreamfeature-B, etc - Feature branches designed to organized
long-term new feature work
Individual developers will then create local development branches
based on those feature branches. If three people are responsible for
tasks for feature-A, they'll create development branches for each
task, do their work, and(via github enterprise) submit a pull request
so we can properly review their work, test it, etc.
The problem I have today stems from situations where a feature branch
has been merged with master. If feature-B is merged with master, and
someone rebases feature-A, there may be merge conflicts. If they fix
the conflicts, that may alter the commit history of the feature
branch, which then impacts all branches developers have based on it.
Part of me feels like we should be able to never rebase feature
branches, they should exist outside of new work merged to master.
However, it's much easier to resolve merge conflicts in small doses,
and we're in a much better position to know that we're fully updated
and can catch other problems early.
Is there a better way to do this, so that we never risk rewriting the
middle tier?
On Tue, Mar 3, 2015 at 3:40 PM, John Keeping j...@keeping.me.uk wrote:
On Tue, Mar 03, 2015 at 03:20:48PM -0800, Mike Botsko wrote:
Maybe I'm lacking the distinction regarding what I'm being specific about.
In both examples, I'm asking it specifically to rebase in changes from
the remote upstream and a named branch at that location. I'm giving
git the same information, it's just interpreting it differently - and
I'm not understanding why.
Not quite. If you say:
git rebase $sha1
then you're telling git-rebase to apply the commits $sha1..HEAD onto
$sha1.
If you say:
git rebase
then it will be re-written as:
git rebase --fork-point @{upstream}
in which case Git will apply more complicated logic so that you can
recover from the case where @{upstream} has been re-written.
Consider the following scenario:
F branch
/
C -- D master@{1}
/
A -- B -- C' -- D' -- E master
where C' and D' are rewritten versions of C and D.
In this case, imagine you are at F on branch, git rebase master will
replace C, D and F onto E because you have explicitly selected to replay
master..branch onto master.
git rebase will apply the fork-point logic and realise that D is a
previous version of master, so it will only replay F onto E.
In general if you just want to rebase onto your upstream it is simpler
to just call git rebase which will do the right thing; it's also
shorter to type ;-)
My local branch would have been created from the
upstream/feature-branch, and will eventually be merged back into it.
Until I'm ready for that, I regularly rebase the work done on
upstream/feature-branch so that my local work is always clean and
above anything else.
In this case the problem stems from the fact that
upstream/feature-branch has been rewritten. Building on top of branches
that will be rewritten is not advisable unless you have a really good
reason to do so.
On Tue, Mar 3, 2015 at 3:15 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
git-rebase assumes that if you give an explicit upstream then you want
precisely what you asked for. From git-rebase(1):
If either upstream or --root is given on the command line,
then the default is `--no-fork-point`, otherwise the default is
`--fork-point`.
Correct.
You ask it to rebase the history without guessing by being explicit;
the command guesses when you are not explicit and being lazy ;-).
--
Mike Botsko
Lead Dev @ Helion3
Ph: 1-(503)-897-0155
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexpected/unexplained difference between git pull --rebase and git rebase
Maybe I'm lacking the distinction regarding what I'm being specific about. In both examples, I'm asking it specifically to rebase in changes from the remote upstream and a named branch at that location. I'm giving git the same information, it's just interpreting it differently - and I'm not understanding why. My local branch would have been created from the upstream/feature-branch, and will eventually be merged back into it. Until I'm ready for that, I regularly rebase the work done on upstream/feature-branch so that my local work is always clean and above anything else. On Tue, Mar 3, 2015 at 3:15 PM, Junio C Hamano gits...@pobox.com wrote: John Keeping j...@keeping.me.uk writes: git-rebase assumes that if you give an explicit upstream then you want precisely what you asked for. From git-rebase(1): If either upstream or --root is given on the command line, then the default is `--no-fork-point`, otherwise the default is `--fork-point`. Correct. You ask it to rebase the history without guessing by being explicit; the command guesses when you are not explicit and being lazy ;-). -- Mike Botsko Lead Dev @ Helion3 Ph: 1-(503)-897-0155 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexpected/unexplained difference between git pull --rebase and git rebase
On Tue, Mar 03, 2015 at 03:20:48PM -0800, Mike Botsko wrote:
Maybe I'm lacking the distinction regarding what I'm being specific about.
In both examples, I'm asking it specifically to rebase in changes from
the remote upstream and a named branch at that location. I'm giving
git the same information, it's just interpreting it differently - and
I'm not understanding why.
Not quite. If you say:
git rebase $sha1
then you're telling git-rebase to apply the commits $sha1..HEAD onto
$sha1.
If you say:
git rebase
then it will be re-written as:
git rebase --fork-point @{upstream}
in which case Git will apply more complicated logic so that you can
recover from the case where @{upstream} has been re-written.
Consider the following scenario:
F branch
/
C -- D master@{1}
/
A -- B -- C' -- D' -- E master
where C' and D' are rewritten versions of C and D.
In this case, imagine you are at F on branch, git rebase master will
replace C, D and F onto E because you have explicitly selected to replay
master..branch onto master.
git rebase will apply the fork-point logic and realise that D is a
previous version of master, so it will only replay F onto E.
In general if you just want to rebase onto your upstream it is simpler
to just call git rebase which will do the right thing; it's also
shorter to type ;-)
My local branch would have been created from the
upstream/feature-branch, and will eventually be merged back into it.
Until I'm ready for that, I regularly rebase the work done on
upstream/feature-branch so that my local work is always clean and
above anything else.
In this case the problem stems from the fact that
upstream/feature-branch has been rewritten. Building on top of branches
that will be rewritten is not advisable unless you have a really good
reason to do so.
On Tue, Mar 3, 2015 at 3:15 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
git-rebase assumes that if you give an explicit upstream then you want
precisely what you asked for. From git-rebase(1):
If either upstream or --root is given on the command line,
then the default is `--no-fork-point`, otherwise the default is
`--fork-point`.
Correct.
You ask it to rebase the history without guessing by being explicit;
the command guesses when you are not explicit and being lazy ;-).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
