Gentoo Archives: gentoo-scm

From: Maciej Mrozowski <reavertm@××××××.fm>
To: gentoo-scm@l.g.o
Subject: Re: [gentoo-scm] Converting a recent CVS copy - Item 3: pushing, availability
Date: Sat, 18 Apr 2009 06:51:28
Message-Id: 200904180851.21962.reavertm@poczta.fm
In Reply to: Re: [gentoo-scm] Converting a recent CVS copy - Item 3: pushing, availability by Arun Raghavan
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

Attachments

File name MIME type
signature.asc application/pgp-signature