Re: git rebase: yet another newbie quest.

[Theodore Ts'o <tytso@mit.edu>]

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...