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 |