Unexpected/unexplained difference between git pull --rebase and git rebase

Unexpected/unexplained difference between git pull --rebase and git rebase

[Mike Botsko]

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

Re: Unexpected/unexplained difference between git pull --rebase and git rebase

[John Keeping]

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)?

Re: Unexpected/unexplained difference between git pull --rebase and git rebase

[Mike Botsko]

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 <john@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

Re: Unexpected/unexplained difference between git pull --rebase and git rebase

[John Keeping]

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 <john@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 majordomo@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

[Junio C Hamano]

John Keeping <john@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 ;-).

Re: Unexpected/unexplained difference between git pull --rebase and git rebase

[Mike Botsko]

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 <gitster@pobox.com> wrote:
> John Keeping <john@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

Re: Unexpected/unexplained difference between git pull --rebase and git rebase

[John Keeping]

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 <gitster@pobox.com> wrote:
> > John Keeping <john@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 ;-).

Re: Unexpected/unexplained difference between git pull --rebase and git rebase

[Mike Botsko]

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 <john@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 <gitster@pobox.com> wrote:
>> > John Keeping <john@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

Re: Unexpected/unexplained difference between git pull --rebase and git rebase

[John Keeping]

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 <john@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 <gitster@pobox.com> wrote:
> >> > John Keeping <john@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html