From: Philip Oakley <philipoakley@iee.org>
Date: Sun, 08 Sep 2013 08:42:03 GMT
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Message-ID: <01BEC88E9B724BA4986F2678A4D9F4E6@PhilipOakley>
In-Reply-To: <CAMP44s2pw2TZSZ6pL-kx_QQCkjKrprERyvddCT-HTeo7uRNENA@mail.gmail.com>

From: "Felipe Contreras" <felipe.contreras@gmail.com>
To: "Philip Oakley" <philipoakley@iee.org>
Cc: "John Keeping" <john@keeping.me.uk>; "Junio C Hamano" 
<gitster@pobox.com>; <git@vger.kernel.org>; "Andreas Krey" 
<a.krey@gmx.de>
Sent: Sunday, September 08, 2013 9:16 AM
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default


> On Sun, Sep 8, 2013 at 3:01 AM, Philip Oakley <philipoakley@iee.org> 
> wrote:
>> 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.
>
> Yes, so you would do:
>
> % git rebase --onto pu
>
> Which would be translated to:
>
> % git rebase @{tail} --onto pu
>
> What's the problem?
>
The 'problem' is (would be) that I don't yet know that I would need 
the --onto pu until I discover (how?) that the default rebase would 
result in conflicts.

>> 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).
>
> Yeah, but almost always you want to rebase onto @{upstream}.

Yeah, but almost always you want to "check" first *before* starting. 
That is, 'git rebase --abort' should not be required from the (user's 
selected /git's) default invocation.

--
Philip Oakley