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

From: Philip Oakley <philipoakley@iee.org>
Date: Sep 5, 2013, 21:30 UTC
Message-ID: <BC4EB62C5077409384A225ECD96D04E1@PhilipOakley>
In-Reply-To: <xmqqr4d4jird.fsf@gitster.dls.corp.google.com>

From: "Junio C Hamano" <gitster@pobox.com>

Show 22 quoted lines

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

Show 7 quoted lines

> 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