Git rebase aggravation

Git rebase aggravation

[Myxz Ptlk]

I have two branches that diverged a long time ago, master and zoo.  I work
locally and check changes into a remote repository.  The remote repository
is also set up the same, and the local branches are set up to track the
remote branches.  Major development has gone on in both sides unfortunately. 
"master" is the production version.  My strategy to get the two together
was:

1)  Rebase master into zoo.

2) Merge zoo into master.

But here is what happens.  I spend 3 hours inside "zoo" doing "git rebase
master".  I go through all the hell of reconciling 6 months of development. 
Then at the end, it just says that the commits now differ between local
"zoo" and "origin/zoo".

So I figure, I will pull from "origin/zoo".  Naturally, that results in a
conflicted merge, which I then clear up.  I commit the merge, then push
everything back to the remote branch.

Now I would guess that my "zoo" branch has everything in it from "master",
and it is also in sync with the  "origin/zoo" branch.  I push and pull and
verify that this is so.

My thinking is that if I were to attempt a new rebase of master, the
beginning of what would be rebased would start from RIGHT NOW, instead of
all the commits over the past 6 months.  To check this, I type:

git rebase master

from "zoo".  Lo and behold, it starts the whole process over again.  I "git
rebase --abort", but I am very, very confused.

Why does the rebase not remember all the freaking work I just did?  Why
would I have to rebase the same commits all over again?  How do people keep
downstream branches up to date if this doesn't work?  What am I missing
here?  I will be extremely grateful for any help and understanding anybody
can offer.
-- 
View this message in context: http://www.nabble.com/Git-rebase-aggravation-tp22155203p22155203.html
Sent from the git mailing list archive at Nabble.com.

Re: Git rebase aggravation

[Nazri Ramliy]

See git help rerere.

It's not enabled by default.

nazri.

Re: Git rebase aggravation

[Thomas Rast]

[-- Attachment #1: Type: text/plain, Size: 2406 bytes --]

Myxz Ptlk wrote:
> 1)  Rebase master into zoo.
> 
> 2) Merge zoo into master.

You may want to consider a merge and topic branch based workflow.  man
gitworkflows has some pointers.

For the rest of the discussion let's assume that your history looks
like

  *---*---*---*  (master)
   \
    \
     o---o---o   (zoo = origin/zoo)

Since you have tracking branches, origin/zoo should be the same as
zoo.  (origin/master should exist too but isn't important for now.)

> But here is what happens.  I spend 3 hours inside "zoo" doing "git rebase
> master".  I go through all the hell of reconciling 6 months of development. 
> Then at the end, it just says that the commits now differ between local
> "zoo" and "origin/zoo".

Indeed, since you rewrote every commit on zoo, it now looks like

  *---*---*---*   (master)
  |            \                 
  |             \                
  \              o'--o'--o'   (zoo)
   \
    o---o---o  (origin/zoo)

> So I figure, I will pull from "origin/zoo".  Naturally, that results in a
> conflicted merge, which I then clear up.  I commit the merge, then push
> everything back to the remote branch.

You're merging like this:

  *---*---*---*   (master)
  |            \                 
  |             \                
  \              o'--o'--o'---M   (zoo)
   \                         /
    o---o---o---------------'
              (origin/zoo)


I think you can already see that you made a mess of history :-)

You should have forced the push instead.  But see "recovering from
upstream rebase" in man git-rebase for information on what happens to
everyone else's work that was based on zoo.

> My thinking is that if I were to attempt a new rebase of master, the
> beginning of what would be rebased would start from RIGHT NOW, instead of
> all the commits over the past 6 months.  To check this, I type:
> 
> git rebase master
> 
> from "zoo".  Lo and behold, it starts the whole process over again.  I "git
> rebase --abort", but I am very, very confused.

Actually it's even worse: it should attempt to rebase _every_ commit
in master..zoo.  If master has progressed since your original
rebase+merge, this will be both the "o" and "o'" commits above.

(Except the ones that did not conflict at all, since they'll still be
the same.)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]