| 1 |
On Saturday 18 of April 2009 07:03:34 Arun Raghavan wrote: |
| 2 |
|
| 3 |
> Just to expand on this, what happens is this. Assume the timelines of |
| 4 |
> the remote and local branches look like this: |
| 5 |
> |
| 6 |
> remote: 1 -- 2 -- 3 -- 4 -- 5 |
| 7 |
> local: 1 -- 2 -- 3 -- a -- b ('a' and 'b' are local commits) |
| 8 |
|
| 9 |
> You last sync'ed your tree at version '3', and want to rebase, so the |
| 10 |
> tree looks like: |
| 11 |
> |
| 12 |
> local: 1 -- 2 --3 --4 -- 5 -- a -- b |
| 13 |
|
| 14 |
Just to make it complete, git pull (without rebase) would result with: |
| 15 |
|
| 16 |
local: 1 -- 2 -- 3 -- a -- b -- 4 -- 5 |
| 17 |
and with dummy 'Merged branch 'master'" commit saying that: |
| 18 |
4 --5 has been appended |
| 19 |
and with commits a -- b appearing somewhere deeper in history (thus making it |
| 20 |
harder to track recent changes). |
| 21 |
|
| 22 |
And about my "locally commited changes are now marked as "remote"": |
| 23 |
|
| 24 |
In situation as above, let's assume there is merge conflict with pull with and |
| 25 |
w/o rebase. |
| 26 |
Conflicts are quite easy to resolve using git mergetool command - it will |
| 27 |
either ask in trivial issues or run some 3-way merging tool if present (like |
| 28 |
kdiff3). In interactive merge tools, those questions or panels will refer to |
| 29 |
"base", "local" and "remote". |
| 30 |
|
| 31 |
While resolving pull *without* rebase: |
| 32 |
1 -- 2 -- 3 (both remote and local) will be marked as "base" |
| 33 |
1 - -2 -- 3 -- 4 -- 5 (so remote comits) will be marked as "remote" |
| 34 |
1 -- 2 --3 -- a -- b (so local commits) will be marked as "local" |
| 35 |
|
| 36 |
But... with --rebase: |
| 37 |
1 -- 2 -- 3 is still marked as "base" |
| 38 |
Then remote (4 -- 5) commits are applied in order against "base" as temporary |
| 39 |
"local" |
| 40 |
(1 -- 2 -- 3) -- 4 -- 5 - so now in fact remote head will be marked as "local" |
| 41 |
Then local commits (a -- b) are tried to be applied |
| 42 |
(1 -- 2 -- 3 -- 4 -- 5) -- a -- b |
| 43 |
And (to make things easier :P) during this procedure, those in fact local |
| 44 |
changes (a--b) will be called "remote". |
| 45 |
|
| 46 |
I guess it's just such terminology, that "local' refers to head that commits |
| 47 |
("remote") are applied against during pull/merge, so "remote" refers to |
| 48 |
incoming changes, no matter where are they from. |
| 49 |
At least that's my understanding backed up by some horrible 3-way |
| 50 |
merging/resolving experience on Manifest files... |
| 51 |
|
| 52 |
Apparently it's possible to enable rebase by default for specific branch in |
| 53 |
git config. |
| 54 |
|
| 55 |
-- |
| 56 |
regards |
| 57 |
MM |
Archives