git rebase: yet another newbie quest.

git rebase: yet another newbie quest.

[Sergey Organov]

Hello,

Caveat: this is somewhat long, sorry.

Recently I've run into yet another rather tricky trouble with
pull/rebase. No, neither of my troubles is in the usual "rewriting
published history" group.

(The first trouble I ran earlier was caused by the fact that "git pull"
breaks local merges when "pull.rebase" configuration variable is set to
"true".)

Below is shell script to create test repo that shows the steps I did
that lead me to the trouble, along with explanations why I did them.
Then follows description of the actual quest I ran through to figure a
work-around.

I must admit I still don't know what I should have done differently in
the script below to avoid this problem in the first place, nor do I
entirely understood what git is doing.

$ git --version
git version 1.9.3

----- 8< -----  Test repo creation ----- 8< -----

#!/bin/sh

# Git output is prefixed with '#> " below

# Prepare some initial state for the show. Create 2 files to be changed
# in 2 different branches to avoid content conflicts later.

git init t
cd t
echo A > a
echo B > b
git add a b
git commit -m "A" -a

# Pretend we have some origin/master. It was really the case in the
# original scenario. Here I just set a tag instead, as it doesn't
# change the outcome.

git tag origin_master

# OK. Here we start. On the branch 'master' (that tracked origin/master in
# original scenario) I do some small change:

echo B >> b
git commit -m B -a

# Then I realize I need more changes and it gets complex enough to
# warrant a topic branch. I create the 'topic' branch that will track
# 'master' branch and reset 'master' back to its origin (remote
# origin/master in original scenario).

git checkout -b topic
git branch --force master origin_master
git branch -u master

# Now I do more work on the topic branch...

echo C >> b
git commit -m C -a

# Meanwhile something non-conflicting (in another file) changed upstream...

git checkout master
echo A >> a
git commit -m D -a
git checkout topic

----- >8 -----  Test repo creation end ----- >8 -----

The creation of the test setup complete, we end-up with the following
simple history:

$ git log --all --oneline --graph --decorate
* 335fc12 (master) D
| * 2cefe9f (HEAD, topic) C
| * aed3006 B
|/
* 951b15b (tag: origin_master) A
$

And my 'topic' branch is set to track 'master':

$ git branch -vv --list topic
* topic 2cefe9f [master: ahead 2, behind 1] C

Exactly what I wanted to achieve. Now we are ready to go to the essence
of the quest.

Being on the 'topic' branch I pull from upstream, rebasing. Can you
guess what I expectated? Yeah, something as simple as B and C being
rebased on top of D, like this:

> $ git pull --rebase
> ...
> $ git log --all --oneline --graph --decorate
> * xxxxxxx (HEAD, topic) C
> * xxxxxxx B
> * 335fc12 (master) D
> * 951b15b (tag: origin_master) A

Here is what I got instead:

$ git pull --rebase
From .
 * branch            master     -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: C
Using index info to reconstruct a base tree...
M	b
Falling back to patching base and 3-way merge...
Auto-merging b
CONFLICT (content): Merge conflict in b
Recorded preimage for 'b'
Failed to merge in the changes.
Patch failed at 0001 C
The copy of the patch that failed is found in:
   /home/osv/f/t/t/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

$

Wait... Conflict?! That's unexpected. Let's first get back to a sane state:

$ git rebase --abort
$

I suspect it's not easy to figure what happens here, even having this
simple imitation. It was even harder in real life as there were a lot of
unrelated things happening simultaneously.

What I did:

Looking closer at the "git rebase" output, it applies C, but not (yet?)
B. Why doesn't it apply B?

Let's first exclude "git pull" from the equation:

$ git rebase
...
$

Still the same outcome as with 'git pull --rebase" above -- at least git
is consistent at kicking me into the stomach ;-) Good...

Let's figure how to check which commits are to be rebased:

$ git help rebase

 "...
  This is the same set of commits that would be shown by
  git log <upstream>..HEAD"

$ git rebase --abort
$ git log --oneline master..HEAD
2cefe9f C
aed3006 B
$

So it should apply B and C, but only applies C. The manual lies?
Unlikely. Let's dig more into the manual... Ah, maybe here it is:

 "Note that any commits in HEAD which introduce the same textual
  changes as a commit in HEAD..<upstream> are omitted "

Check...

$ git log --oneline HEAD..master
335fc12 D
$

No, there is no way missed commit 'B' textually matches commit 'D'.

Wondering further... let's try to specify <upstream> explicitly:

$ git --rebase master
First, rewinding head to replay your work on top of it...
Applying: B
Applying: C
$

Wow! This way it works! But the manual says:

 "If <upstream> is not specified, the upstream configured in
  branch.<name>.remote and branch.<name>.merge options will be
  used; see git-config(1) for details."

Did I mis-configured <upstream>? Check:

$ git config --list | grep topic
branch.topic.remote=.
branch.topic.merge=refs/heads/master
$

# So it's 'refs/heads/master'. I always thought I can say just 'master',
# but let's see if it suddenly matters in this case?:

$ git reset --hard @{1} # First get to pre-rebase state
HEAD is now at 2cefe9f C
$ git --rebase refs/heads/master
First, rewinding head to replay your work on top of it...
Applying: B
Applying: C
$

Still different from what vanilla "git rebase" does. So, what's next?
How do I figure what exactly it does? Searching for "debug", "verbose",
"dry-run", or something like that in the manual page. Well, there is
'-v', try it:

$ git reset --hard @{1}
HEAD is now at 2cefe9f C
$ git rebase -v
Changes from 951b15b8bfd6dee3d22ed1c48b0d2947aefac346 to 335fc12a2ddd175a22e086a08492ceda1280fd9f:
 a | 1 +
 1 file changed, 1 insertion(+)
First, rewinding head to replay your work on top of it...
Applying: C
Using index info to reconstruct a base tree...
M	b
Falling back to patching base and 3-way merge...
Auto-merging b
CONFLICT (content): Merge conflict in b
Recorded preimage for 'b'
Failed to merge in the changes.
Patch failed at 0001 C
The copy of the patch that failed is found in:
   /home/osv/f/t/t/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

$

Doesn't help either, no luck.

Well, how does it calculate the set of commits? Probably it has
something to do with merge-base? (Yeah, I already knew about merge-base
as I wrote script to convert our CVS repository to git and learned a few
things on the way, so I'm not entirely newbie.)

$ git help merge-base
...

And there, right in SYNOPSIS, the --fork-point catches my attention.
Reading its description:

--fork-point
    Find the point at which a branch (or any history that leads to
    <commit>) forked from another branch (or any reference) <ref>. This
    does not just look for the common ancestor of the two commits, but
    also takes into account the reflog of <ref> to see if the history
    leading to <commit> forked from an earlier incarnation of the branch
    <ref> (see discussion on this mode below). :

It definitely clicks! Let's look for --fork-point in the

$ git help rebase

Yeah, it's there!

--fork-point, --no-fork-point
    Use git merge-base --fork-point to find a better common ancestor
    between upstream and branch when calculating which commits have have
    been introduced by branch (see git-merge-base(1)).

    If no non-option arguments are given on the command line, then the
    default is --fork-point @{u} otherwise the upstream argument is
    interpreted literally unless the --fork-point option is specified.


So, this last paragraph, hidden deep in the middle of the lengthy git
rebase manual page, brings us the answer:

"git rebase"      ==  "git rebase --fork-point @{u}"

while

"git rebase @{u}" ==  "git rebase --no-fork-point @{u}"

Surprise!

And the set of commits vanilla "git rebase" will rebase could apparently
be rather different from those output by

"git log @{u}..HEAD"

that the manual unconditionally claims in the DESCRIPTION.

... And after I wrote the above, out of curiosity I tried the following
(I've already re-created the test repo, so SHA1s won't match):

$ git pull --no-rebase --no-edit
From .
 * branch            master     -> FETCH_HEAD
Merge made by the 'recursive' strategy.
 a | 1 +
 1 file changed, 1 insertion(+)
$ git pull --rebase
From .
 * branch            master     -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: B
Applying: C
$

So, if I first do pull/merge, then pull/rebase suddenly starts to do
what I asked it to do in the first place! That throws me back right into
the middle of the quest!

$ git reset --hard @{1}
HEAD is now at ed1ff0f Merge branch 'master' into topic
$ git log $(git merge-base --fork-point @{u} HEAD)..HEAD
<no output>
$ git merge-base --fork-point @{u} HEAD
<no output>
$ git log --one-line ${u}..HEAD
ed1ff0f Merge branch 'master' into topic
ff4d9fa C
e326c16 B
$

So, when there is no fork-point found, vanilla "git rebase" behaves as
if it were "git rebase @{u}"? I still neither understand what exactly
happens here, nor what all this --fork-point business is all about in
the first place.

How comes fork point disappears because of merge, and is it OK that
'merge-base --fork-point' produces no output at all when vanilla
'merge-base' does?

Could somebody please fix the manual page to explain what "git rebase"
is actually doing? I mean somebody who, unlike me, actually knows,

Also, what should I have done differently in the script above to avoid
the problem in the first place? Is it git bug I stumbled over?

P.S. On the positive side, it reminded me playing good old Larry game in
     the early 90's :-)

-- 
Sergey.

Re: git rebase: yet another newbie quest.

[Theodore Ts'o]

I'm not going to say what you *should* have done, since it's not clear
whether anything close to what you were doing is a supported workflow.
But I can tell you what I *do* myself.  Personally, I vastly distrust
git pull --rebase.

So in general, my pulls are all the equivalent of "git pull
--ff-only", and if I want to rebase the topic branch (which in
general, is a bad idea to do regularly; I will generally not do it at
all until I'm almost done).  So I'll branch the topic branch off of
origin (which tracks origin/master, typically):

git checkout -b topic1 origin
<hack hack hack>
git commit
    .
    .
    .


Then I might do something like this to do a build:

git fetch origin ; git branch -f origin origin/master    # this is optional
git checkout -B build origin
git merge topic1
git merge topic2
    ...
<make>

In general, I will only rebase a topic branch when it's needed to fix
a serious conflcit caused by significant changes upstream.  And in
that case, I might do something like this:

git checkout topic1
git rebase origin/master
<make>
<make check>


This basically goes to a philosophical question of whether it's
simpler to tell users to use a single command, such as "git pull
--rebase", or whether to tell users to use a 2 or 3 commands that
conceptually much more simple.  Personally, I type fast enough that I
tend to use simple commands, and not try to use things like automated
branch tracking.  That way I don't have to strain my brain thinking
about things like "fork points".  :-)

OTOH, some people feel that it's better to make things like "git pull
--rebase" work and do the right thing automatically, because
<competing DSCM> allows you to do it in a single command.  And indeed,
if you use "git pull --rebase" without any topic branches, it works
fine.  But then when you start wanting to do things that are more
complicated, the automated command starts getting actually harder and
more confusing (at least in my opinion).  

I don't know if a workflow involving topic branches was even expected
to work with "git pull --rebase", and if so, how to set things up so
that they do work smoothly.  All I know is that the issue never arises
with me, because it's rare that I use git pull, let alone git pull
--rebase.  That's because I usually like to take a quick look at what
I've pulled (using gitk, or git log) before do the merge operation.

If I'm doing a pull from a repo that I control, and so I think I'm
sure I know what's there, I might skip the "git fetch", and do a "git
pull --ff-only" instead.  But in general I prefer to do the merging
separate from the pull operation.

Cheers,

						- Ted

P.S.  There is a separate, and completely valid discussion which is
how to prevent a newbie from falling into a same trap you did.  I'll
defer that discussion to others...

Re: git rebase: yet another newbie quest.

[John Keeping]

On Fri, Sep 05, 2014 at 02:28:46PM +0400, Sergey Organov wrote:
...
> # Then I realize I need more changes and it gets complex enough to
> # warrant a topic branch. I create the 'topic' branch that will track
> # 'master' branch and reset 'master' back to its origin (remote
> # origin/master in original scenario).
> 
> git checkout -b topic
> git branch --force master origin_master

This line is the problem, because the purpose of the `--fork-point`
argument to `git rebase` is designed to help people recover from
upstream rebases, which is essentially what you create here.  So when
rebase calculates the local changes it realises (from the reflog) that
the state of master before this command was before you created the
branch, so only commits after it should be picked.

For the case when the upstream of a branch is remote, this is normally
what you want.

Re: git rebase: yet another newbie quest.

[Sergey Organov]

John Keeping <john@keeping.me.uk> writes:

> On Fri, Sep 05, 2014 at 02:28:46PM +0400, Sergey Organov wrote:
> ...
>> # Then I realize I need more changes and it gets complex enough to
>> # warrant a topic branch. I create the 'topic' branch that will track
>> # 'master' branch and reset 'master' back to its origin (remote
>> # origin/master in original scenario).
>> 
>> git checkout -b topic
>> git branch --force master origin_master
>
> This line is the problem, because the purpose of the `--fork-point`
> argument to `git rebase` is designed to help people recover from
> upstream rebases, which is essentially what you create here.  So when
> rebase calculates the local changes it realises (from the reflog) that
> the state of master before this command was before you created the
> branch, so only commits after it should be picked.

Thanks, but I did realize it myself (after I spent a few hours figuiring
it out). The question is what should I have done instead?

-- 
Sergey.

Re: git rebase: yet another newbie quest.

[Sergey Organov]

Theodore Ts'o <tytso@mit.edu> writes:
> I'm not going to say what you *should* have done, since it's not clear
> whether anything close to what you were doing is a supported workflow.
> But I can tell you what I *do* myself.  Personally, I vastly distrust
> git pull --rebase.

Thank you for sharing your experience!

In the particular case at hand though, "git rebase" is the actual cause
of the problem, not "git pull --rebase".

> So in general, my pulls are all the equivalent of "git pull
> --ff-only", and if I want to rebase the topic branch (which in
> general, is a bad idea to do regularly; I will generally not do it at
> all until I'm almost done).  So I'll branch the topic branch off of
> origin (which tracks origin/master, typically):
>
> git checkout -b topic1 origin
> <hack hack hack>
> git commit
>
>   ...
> <make>
>
> In general, I will only rebase a topic branch when it's needed to fix
> a serious conflcit caused by significant changes upstream.  And in
> that case, I might do something like this:
>
> git checkout topic1
> git rebase origin/master
> <make>
> <make check>

Yeah, it's a good way to do things, but for most of quick fixes I'm lazy
to create topic branch, and in this case it lead to a nasty unexpected
trouble.

I didn't intend to make topic branch from the very beginning, and
already made a commit or two on the remote tracking branch bofore I
realized I'd better use topic branch. It'd create no problem as far as I
can see, provided vanilla "git rebase" has "sane" defaults. That said,
I've already been once pointed to by Junio that my definition of "sane"
doesn't take into account workflows of others, so now I try to be
carefull calling vanilla "git rebase" names.

Please also notice that I didn't pull immediately after I've re-arranged
my branches, and this fact only made it more difficult to find and
isolate the problem.

[...]

> P.S.  There is a separate, and completely valid discussion which is
> how to prevent a newbie from falling into a same trap you did.  I'll
> defer that discussion to others...

Yeah, it'd be fine if at least documentation is fixed.

-- 
Sergey.

Re: git rebase: yet another newbie quest.

[Theodore Ts'o]

On Mon, Sep 08, 2014 at 05:52:44PM +0400, Sergey Organov wrote:
> 
> I didn't intend to make topic branch from the very beginning, and
> already made a commit or two on the remote tracking branch bofore I
> realized I'd better use topic branch. It'd create no problem as far as I
> can see, provided vanilla "git rebase" has "sane" defaults. That said,
> I've already been once pointed to by Junio that my definition of "sane"
> doesn't take into account workflows of others, so now I try to be
> carefull calling vanilla "git rebase" names.

Right, so what I typically in that situation is the following:

<on the master branch>
<hack hack hack>
git commit
<hack hack hack>
git commit
<oops, I should have created a topic branch>
git checkout -b topic-branch
git branch -f master origin/msater

This resets the master branch to only have what is in the upstream
commit.

> Please also notice that I didn't pull immediately after I've re-arranged
> my branches, and this fact only made it more difficult to find and
> isolate the problem.

It's also the case that I rarely will do a "git rebase" without taking
a look at the branches to make sure it will do what I expect.  I'll do
that using either "gitk" or "git lgt", where git lgt is defined in my
.gitconfig as:

[alias]
	lgt = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit

And typically what I will do is something like this:

gitk -20 master origin/master topic

-or-

git lgt -20 master origin/master topic

The "git lgt" command is very handy when I want to see how the
branches are arranged, and I'm logged remotely over ssh/tmux or some
such, so gitk isn't really available to me.

Cheers,

						- Ted

Re: git rebase: yet another newbie quest.

[Sergey Organov]

Theodore Ts'o <tytso@mit.edu> writes:

> On Mon, Sep 08, 2014 at 05:52:44PM +0400, Sergey Organov wrote:
>> 
>> I didn't intend to make topic branch from the very beginning, and
>> already made a commit or two on the remote tracking branch bofore I
>> realized I'd better use topic branch. It'd create no problem as far as I
>> can see, provided vanilla "git rebase" has "sane" defaults. That said,
>> I've already been once pointed to by Junio that my definition of "sane"
>> doesn't take into account workflows of others, so now I try to be
>> carefull calling vanilla "git rebase" names.
>
> Right, so what I typically in that situation is the following:
>
> <on the master branch>
> <hack hack hack>
> git commit
> <hack hack hack>
> git commit
> <oops, I should have created a topic branch>
> git checkout -b topic-branch
> git branch -f master origin/msater
>
> This resets the master branch to only have what is in the upstream
> commit.

But that's *exactly* what lead me to the problem! Here is relevant part
of my script:

git checkout -b topic
git branch --force master origin_master
git branch -u master

except that I wanted to configure upstream as well for the topic-branch,
that looks like pretty legit desire. If I didn't, I'd need to specify
upstream explicitly in the "git rebase", and I'd not notice the problem
at all, as the actual problem is that "git rebase" and "git rebase
<upstream>" work differently!

-- Sergey.

P.S. Nice 'lgt' alias, BTW. I simply use:

$ git help hist
git hist' is aliased to `log --oneline --graph --decorate'

stolen somewhere.

Re: git rebase: yet another newbie quest.

[Theodore Ts'o]

On Mon, Sep 08, 2014 at 07:47:38PM +0400, Sergey Organov wrote:
> 
> except that I wanted to configure upstream as well for the topic-branch,
> that looks like pretty legit desire. If I didn't, I'd need to specify
> upstream explicitly in the "git rebase", and I'd not notice the problem
> at all, as the actual problem is that "git rebase" and "git rebase
> <upstream>" work differently!

Right, so I never do that.  I have master track origin/master, where
it automagically does the right thing, but I'm not even sure I can
articulate what it *means* to have topic also track origin/master.  I
just don't have a mental model for it, and so it falls in the category
of "it's too complicated for my simple brain to figure out".

So I just do "git rebase master", and I would never even *consider*
doing a "git pull --rebase".  I'll do a "git fetch", and then look at
what just landed, and and then checkout master, update it to
origin/master, and then run the regression tests to make sure what
just came in from outside actually was *sane*, and only then would I
do a "git checkout topic; git rebase master", and then re-run the
regression tests a third time.

Otherwise, how would I know whether the regression came in from
origin/master, or from my topic branch, or from the result of rebasing
the topic branch on top of origin/master?

And of course, this goes back to my observation that I don't rebase my
topic branchs all that often anyway, just because the moment you do
the rebase, you've invalidated all of the testing that you've done to
date.  In fact, some upstreams will tell explicitly tell you to never
rebase a topic branch before you ask them to pull it in, unless you
need to handle some non-trivial merge conflict.

Cheers,

						- Ted

Re: git rebase: yet another newbie quest.

[Sergey Organov]

Theodore Ts'o <tytso@mit.edu> writes:

> On Mon, Sep 08, 2014 at 07:47:38PM +0400, Sergey Organov wrote:
>> 
>> except that I wanted to configure upstream as well for the topic-branch,
>> that looks like pretty legit desire. If I didn't, I'd need to specify
>> upstream explicitly in the "git rebase", and I'd not notice the problem
>> at all, as the actual problem is that "git rebase" and "git rebase
>> <upstream>" work differently!
>
> Right, so I never do that.  I have master track origin/master, where
> it automagically does the right thing, but I'm not even sure I can
> articulate what it *means* to have topic also track origin/master.

You got it somewhat wrong. I intended 'topic' to track 'master', not
'origin/master'.

> I just don't have a mental model for it, and so it falls in the category
> of "it's too complicated for my simple brain to figure out".

I thought it's rather common for one local branch to track another in
the git world. At least all machinery is there, and I don't see how
tracking local branch is different from tracking remote branch,
fundamentally.

> So I just do "git rebase master", and I would never even *consider*
> doing a "git pull --rebase".  I'll do a "git fetch", and then look at
> what just landed, and and then checkout master, update it to
> origin/master, and then run the regression tests to make sure what
> just came in from outside actually was *sane*, and only then would I
> do a "git checkout topic; git rebase master", and then re-run the
> regression tests a third time.

Yeah, and I simply wanted to shorten it to "git checkout topic; git
rebase", by making git remember I want to rebase w.r.t. 'master' by
default. 

> Otherwise, how would I know whether the regression came in from
> origin/master, or from my topic branch, or from the result of rebasing
> the topic branch on top of origin/master?

As far as I can see, what I did is almost exactly what you do, except I
didn't want to tell "master" every time I want to rebase 'topic' branch.
Configuring tracking branch and saying just "git rebase" when you are on
the branch seems to be logical, and there doesn't seem to be anything
wrong with it (except strange git default behavior), or does it?

> And of course, this goes back to my observation that I don't rebase my
> topic branchs all that often anyway, just because the moment you do
> the rebase, you've invalidated all of the testing that you've done to
> date.  In fact, some upstreams will tell explicitly tell you to never
> rebase a topic branch before you ask them to pull it in, unless you
> need to handle some non-trivial merge conflict.

That's good advice indeed, but it's unrelated to the issue at hand, as you
still rebase, sooner or later.

-- 
Sergey.