Re: git rebase: yet another newbie quest.

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