delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2012/10/23/20:02:50

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.ud03.udmedia.de; h=
mime-version:in-reply-to:references:content-type:message-id
:content-transfer-encoding:from:subject:date:to; s=beta; bh=o6JN
RkDpmrTDcYmArek6ied9yqnHrlvfIjLcbwNF6SU=; b=tGFQG6J5MLX/aopPqoWq
kvgivWn+qpzzpg/bFpCIb9SUfNjhzu0J3BXgOUReLT3OJiH4JWkzMpg2IwuThIJ4
BGareMGhkk7m+fa2FThhHOM/0/nUZNbwOCfBI2gWX4UP8IkCRCpwKBk2ydGFCHxy
euNcHQfLW31QGR+FS6C4dTg=
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <20121023233036.1882.qmail@stuge.se>
References: <5086B5AD DOT 9080706 AT estechnical DOT co DOT uk> <CAPYb0EGLoBRUWzokBzsHbacMU8RhnfFnnq+-_+JQB_9m5V9E0Q AT mail DOT gmail DOT com> <5086C5E4 DOT 7060900 AT estechnical DOT co DOT uk> <20121023194935 DOT 37dd2ef5 AT Parasomnia DOT thuis DOT lan> <14298605-8530-4818-83C8-B242AAFFEF9A AT jump-ing DOT de> <20121023233036 DOT 1882 DOT qmail AT stuge DOT se>
Message-Id: <C07F3209-0B9C-4A3F-B1DB-4FD0FB8C0909@jump-ing.de>
From: Markus Hitter <mah AT jump-ing DOT de>
Subject: Re: [geda-user] Odd position mangling error
Date: Wed, 24 Oct 2012 02:11:46 +0200
To: geda-user AT delorie DOT com
X-Mailer: Apple Mail (2.753.1)
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Am 24.10.2012 um 01:30 schrieb Peter Stuge:

> Markus Hitter wrote:
>> Either in one chunk with
>>
>> git checkout work
>> git rebase master
>>
>> or in small steps with
>>
>> git checkout work
>> git rebase e
>> git rebase f
>> git rebase master
>>
>> The latter is more on the safe side, as smaller rebases have fewer  
>> reasons
>> for conflicts. You can always try the fast one first, then git rebase
>> --abort on failure and try again with the second variant.
>
> The two are equivalent, just that the former method saves a lot of
> typing. The result will be identical ...

Doesn't match my knowledge and experience.

git rebase replays the commits making a branch right onto the commit  
it is rebased to. The two procedures make no difference if all  
changes between the old and the new master are all in different  
places, but it makes a difference when you have places which were  
changed several times. The latter is likely when you catch up a  
year's worth of remote commits.

Imagine the remote repo sent several changes to the same file in  
about the same place. One of these changes matches a change in your  
local branch. If you rebase right onto the top of the new master,  
you'll get a conflict. If you rebase in small chunks one of the  
remote changes will match your local change and the local change will  
disappear. You've chances to get away without conflict.

That, plus resolving small conflicts is always waaay easier than  
battling a hundred of them at once.


Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/





- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019