GIT rebase changes

[Mike McCormack]

Hi GIT users,

The GIT guys have made rebase and pull incompatible, and to use rebase 
(which is likely what we want to do for Wine), you must use "fetch" then 
"rebase", not "pull" (which does a merge).

See:  http://article.gmane.org/gmane.linux.kernel/365410

The error message that you get if you use "pull" then try to "rebase" 
with newer version of GIT is pretty useless:

bash-3.00$ git-rebase origin
Current branch refs/heads/master is up to date.

So use "git-fetch" to update origin, then "git-rebase origin" after that 
to get the new changes.  I've update the Wiki with that information - 
don't shoot the messenger :/

Mike

[Michael Stefaniuc]

Hi!

Mike McCormack wrote:
> The GIT guys have made rebase and pull incompatible, and to use rebase 
> (which is likely what we want to do for Wine), you must use "fetch" then 
> "rebase", not "pull" (which does a merge).

Depends if you want to keep your old history or not. "git pull" works 
nicely.
> See:  http://article.gmane.org/gmane.linux.kernel/365410
>
> The error message that you get if you use "pull" then try to "rebase" 
> with newer version of GIT is pretty useless:

I run into this yesterday. My master had the same code but different 
history than origin. Did a git rebase (after branching my master so i 
can keep my old history) and expected it to make master identical to 
origin. I know i can achieve the same by copying the origin head over to 
the master head but that would be like cheating.

I'm still pondering what makes more sense:
- to keep my old history, or
- rebase to origin every now and then to easier spot the differences 
between master and origin.
> bash-3.00$ git-rebase origin
> Current branch refs/heads/master is up to date.
>
> So use "git-fetch" to update origin, then "git-rebase origin" after that 
> to get the new changes.  I've update the Wiki with that information - 
> don't shoot the messenger :/

bye
    michael

[Michael Stefaniuc]

I hate to reply to myself, but ...

Michael Stefaniuc wrote:
> Mike McCormack wrote:
> > The GIT guys have made rebase and pull incompatible, and to use rebase 
> > (which is likely what we want to do for Wine), you must use "fetch" 
> > then "rebase", not "pull" (which does a merge).
>
> Depends if you want to keep your old history or not. "git pull" works 
> nicely.
> > See:  http://article.gmane.org/gmane.linux.kernel/365410
> >
> > The error message that you get if you use "pull" then try to "rebase" 
> > with newer version of GIT is pretty useless:
>
> I run into this yesterday. My master had the same code but different 
> history than origin. Did a git rebase (after branching my master so i 
> can keep my old history) and expected it to make master identical to 
> origin. I know i can achieve the same by copying the origin head over to 
> the master head but that would be like cheating.
>
> I'm still pondering what makes more sense:
> - to keep my old history, or

And this screws you up when you do git-format-patch. My VarCmp patches 
in my master tree where composed out of a ton of separate small patches 
(took me some time to have that function figured out) and now 
git-format-patch dumped those out too even that my master branch and 
origin where code wise the same. Quite annoying.
> - rebase to origin every now and then to easier spot the differences
>
> between master and origin.

Mike, you were right, "git rebase" is what we want to use. But if you do 
not have patches sent to upstream "git pull" works too and it's faster 
to type.

bye
    michael

[Robert Shearman]

Mike McCormack wrote:
> Hi GIT users,
>
> The GIT guys have made rebase and pull incompatible, and to use rebase 
> (which is likely what we want to do for Wine), you must use "fetch" 
> then "rebase", not "pull" (which does a merge).

And on a slightly related note, I wrote a script which works kinda like 
rebase (and is based on the old version of rebase) that allows you to 
coalesce two patches in your tree. This is useful in two situations:
1. You commit a new feature and then realise after some extensive 
testing that there is a bug, so you commit a fix, don't want to send the 
two separate patches to wine-patches (maybe to save face :-), or maybe 
to reduce noise).
2. You revert a patch in your tree but don't want both the revert and 
the old patch in your patch queue as shown by git-format-patch or by 
Mike's mm-send-patch.

Note that the first commit chronologically must be the first commit on 
the command line.