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

From: "Philip Oakley" <philipoakley@iee.org>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "John Keeping" <john@keeping.me.uk>,
	"Felipe Contreras" <felipe.contreras@gmail.com>,
	"Git List" <git@vger.kernel.org>, "Andreas Krey" <a.krey@gmx.de>
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Date: Thu, 5 Sep 2013 22:30:34 +0100	[thread overview]
Message-ID: <BC4EB62C5077409384A225ECD96D04E1@PhilipOakley> (raw)
In-Reply-To: xmqqr4d4jird.fsf@gitster.dls.corp.google.com

From: "Junio C Hamano" <gitster@pobox.com>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> From: "Junio C Hamano" <gitster@pobox.com>
>>> John Keeping <john@keeping.me.uk> writes:
>>>
>>>> I think there are two distinct uses for pull, which boil down to:
>>>>
>>>>     (1) git pull
>>> ...
>>> Peff already covered (1)---it is highly doubtful that a merge is
>>> "almost always wrong".  In fact, if that _were_ the case, we should
>>> simply be defaulting to rebase, not failing the command and asking
>>> between merge and rebase like jc/pull-training-wheel topic did.
>>>
>>> We simply do not know what the user wants, as it heavily depends on
>>> the project, so we ask the user to choose one (and stick to it).
>>
>> We only offer a limited list. It won't be sufficient for all use
>> cases. It wasn't for me.
>
> Very interesting. Tell us more.
>
What I do now is avoid Pull because of the hassle of fixing anything
that may have gone wrong.

Instead I now use a 'git fetch', followed by a 'push . (+etc:etc)' once 
I understand what I've got, or what I need to do different if wasn't a 
simple fast forward 'pull'.

> When "git pull" stops because what was fetched in FETCH_HEAD does
> not fast-forward, then what did _you_ do (and with the knowledge you
> currently have, what would you do)?  In a single project, would you
> choose to sometimes rebase and sometimes merge, and if so, what is
> the choice depend on?  "When I am on these selected branches, I want
> to merge, but on other branches I want to rebase?"
>

In my case I have two home machines (main Windows machine and an 
occasional Linux laptop, though not directly networked together) and 
github as my level group, and have MSysGit and git/git (on github) as 
true upstreams, though they haven't been named that way [Aside: we are 
short of a good name for one's 'across-stream server' that one uses for 
backup/transfer such as github].

I general now use a forced update to bring my local machine up to date 
relative to whatever is upstream or on my across stream server, such as 
when transferring development from one machine to the other (where 
overwrite is the desired action) - e.g. when testing on the Linux laptop 
and a few corrections, before patch preparation on the Windows machine 
(different levels of familiarity).

I occasionally will need to rebase my topic onto an updated git/master 
or git/pu if it is to be submitted upstream (patches to the list) or if 
upstream has moved, though I want to choose where I will rebase the 
topic onto. I don't need merging in that scenario, as I see those via 
your git repo ;-)

It's not clear to me that a single default that uses a merge or rebase, 
without a 'stop if' criteria would be of any help in my situation.

My thoughts are that the options on a fetch-pull are for the branch to 
be:
* Overwritte (--force) (i.e. a conflict scenario)
* Stop if not-ff (conflict scenario, this patch series)
* rebase existing onto tracked [not a conflict in terms of initiation]
* merge existing into tracked [not a conflict in terms of initiation]
* fast-forward (bring tracked onto existing) [desired]

Philip