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

From: Felipe Contreras <felipe.contreras@gmail.com>
To: John Keeping <john@keeping.me.uk>
Cc: Junio C Hamano <gitster@pobox.com>,
	Philip Oakley <philipoakley@iee.org>,
	git@vger.kernel.org, Andreas Krey <a.krey@gmx.de>
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Date: Sat, 7 Sep 2013 21:34:51 -0500	[thread overview]
Message-ID: <CAMP44s1Rb2WKGD-QfNh055099R+9FHv9W8TA8Gfjp=qZh_7p7Q@mail.gmail.com> (raw)
In-Reply-To: <20130905080606.GE2582@serenity.lan>

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

-- 
Felipe Contreras