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

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>
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Date: Sun, 8 Sep 2013 03:16:06 -0500	[thread overview]
Message-ID: <CAMP44s2pw2TZSZ6pL-kx_QQCkjKrprERyvddCT-HTeo7uRNENA@mail.gmail.com> (raw)
In-Reply-To: <8B7F235220624B259BB32B293BCB3E96@PhilipOakley>

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?

> 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}.

-- 
Felipe Contreras