Re: [PATCH 0/3] Reject non-ff pulls by default

From: "Philip Oakley" <philipoakley@iee.org>
To: "Felipe Contreras" <felipe.contreras@gmail.com>,
	"John Keeping" <john@keeping.me.uk>
Cc: "Junio C Hamano" <gitster@pobox.com>, <git@vger.kernel.org>,
	"Andreas Krey" <a.krey@gmx.de>
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Date: Sun, 8 Sep 2013 09:01:14 +0100	[thread overview]
Message-ID: <8B7F235220624B259BB32B293BCB3E96@PhilipOakley> (raw)
In-Reply-To: CAMP44s1Rb2WKGD-QfNh055099R+9FHv9W8TA8Gfjp=qZh_7p7Q@mail.gmail.com

From: "Felipe Contreras" <felipe.contreras@gmail.com>
Sent: Sunday, September 08, 2013 3:34 AM
> On Thu, Sep 5, 2013 at 3:06 AM, John Keeping <john@keeping.me.uk> 
> wrote:
>> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
>>> Are there cases where you do not want to either rebase nor merge?
>>> If so what do you want to do after "git pull" fetches from the other
>>> side?  Nothing?
>>
>> One other thing that I can see being useful occasionally is:
>>
>>     git rebase @{u}@{1} --onto @{u}
>>
>> which allows local commits to be replayed onto a rewritten upstream
>> branch.
>>
>> Although I agree with your side note below that people doing this may 
>> be
>> better off fetching and then updating their local branch, 
>> particularly
>> if @{1} is not the correct reflog entry for the upstream when they
>> created the branch.
>
> That's why after recognizing the fact the you can't find the branch
> point of a branch in Git, I decided to write patches to support the
> @{tail} shorthand, which is basically the point where the branch was
> created, or rebased to:
>
> https://github.com/felipec/git/commits/fc/base
>
> And if 'git rebase' was fixed to ignore the commits already in the
> rebased onto branch, almost always what you would want to do is 'git
> rebase @{tail} --onto @{upstream}'.
>
The use case that trips me up (i.e. doesn't fit the above) is when I 
have a branch that may need rebasing on (onto) pu, or may need rebasing 
on master, or next, depending on what others have been doing.

As a Distributed VCS (i.e. others doing work independently), a rebase 
always has the possibility that the world has moved on and one has to 
adapt to the new world order by moving location (--onto somewhere new), 
not just fixing up the house (patch conflicts). When the update order is 
unknown there is no guaranteed solution (IIUC).

You are right that mostly what one wants to do is stick with ones 
current location and patch up conflicts, it's just that one din't want 
any conflicts in the first place (i.e. the fast forward check). 