On Saturday 18 of April 2009 07:03:34 Arun Raghavan wrote:

> Just to expand on this, what happens is this. Assume the timelines of
> the remote and local branches look like this:
>
> remote: 1 -- 2 -- 3 -- 4 -- 5
> local:  1 -- 2 -- 3 -- a -- b ('a' and 'b' are local commits)

> You last sync'ed your tree at version '3', and want to rebase, so the
> tree looks like:
>
> local:  1 -- 2 --3 --4 -- 5 -- a -- b

Just to make it complete, git pull (without rebase) would result with:

local: 1 -- 2 -- 3 -- a -- b -- 4 -- 5
and with dummy 'Merged branch 'master'" commit saying that:
4 --5 has been appended
and with commits a -- b appearing somewhere deeper in history (thus making it 
harder to track recent changes).

And about my "locally commited changes are now marked as "remote"":

In situation as above, let's assume there is merge conflict with pull with and 
w/o rebase.
Conflicts are quite easy to resolve using git mergetool command - it will 
either ask in trivial issues or run some 3-way merging tool if present (like 
kdiff3). In interactive merge tools, those questions or panels will refer to 
"base", "local" and "remote".

While resolving pull *without* rebase:
1 -- 2 -- 3 (both remote and local) will be marked as "base"
1 - -2 -- 3 -- 4 -- 5 (so remote comits) will be marked as "remote"
1 -- 2 --3 -- a -- b (so local commits) will be marked as "local"

But... with --rebase:
1 -- 2 -- 3 is still marked as "base"
Then remote (4 -- 5) commits are applied in order against "base" as temporary 
"local"
(1 -- 2 -- 3) -- 4 -- 5 - so now in fact remote head will be marked as "local"
Then local commits (a -- b) are tried to be applied
(1 -- 2 -- 3 -- 4 -- 5) -- a -- b
And (to make things easier :P) during this procedure, those in fact local 
changes (a--b) will be called "remote".

I guess it's just such terminology, that "local' refers to head that commits 
("remote") are applied against during pull/merge, so "remote" refers to 
incoming changes, no matter where are they from.
At least that's my understanding backed up by some horrible 3-way 
merging/resolving experience on Manifest files...

Apparently it's possible to enable rebase by default for specific branch in 
git config.

-- 
regards
MM