Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-scm
Navigation:
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-scm@g.o
From: Maciej Mrozowski <reavertm@...>
Subject: Re: Converting a recent CVS copy - Item 3: pushing, availability
Date: Sat, 18 Apr 2009 08:51:21 +0200
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
Attachment:
signature.asc (This is a digitally signed message part.)
References:
Converting a recent CVS copy - Item 3: pushing, availability
-- Robin H. Johnson
Re: Converting a recent CVS copy - Item 3: pushing, availability
-- William Hubbs
Re: Converting a recent CVS copy - Item 3: pushing, availability
-- Arun Raghavan
Navigation:
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Converting a recent CVS copy - Item 3: pushing, availability
Next by thread:
git tree policies?
Previous by date:
Re: Converting a recent CVS copy - Item 3: pushing, availability
Next by date:
Re: 'overlays' are altenatives to full tree clone


Updated Jun 17, 2009

Summary: Archive of the gentoo-scm mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.