Re: Pull is Evil

From: David Kastrup <dak@gnu.org>
Date: May 2, 2014, 08:46 UTC
Message-ID: <87wqe4y3e6.fsf@fencepost.gnu.org>
In-Reply-To: <20140502074027.GB6288@inner.h.apk.li>

Andreas Krey <a.krey@gmx.de> writes:

Show 11 quoted lines

> On Wed, 30 Apr 2014 13:01:49 +0000, Junio C Hamano wrote:
> ...
>> I didn't mean "replace 'pull' with 'update' everywhere".  I meant
>> "Introduce 'update' that lets integrate your history into that from
>> the remote, which is to integrate in a direction opposite from how
>> 'pull' does".  
>
> That still doesn't quite solve my problem. If I'm tracking origin/master
> in a local master branch, I can just use 'git pull' to get my 'feature'
> branch (which is named master) updated to the current state of the origin.
> This amounts to 'integrating' origin/master into my master.

This discussion makes as much sense to me as debating whether "git fiddle" should, in case a simple "git hammer" does not apply, should translate to an implied "git screwdriver", and when it does, whether more people's workflows involve turning a screw left rather than right by default.

What the gibbins? I don't even use git pull. I use git fetch, and then, depending on my needs, I rebase or merge. git pull is not part of my workflow exactly because it does non-connected things not translating unambiguously to a particular identifiable workflow. It might sometimes, more by accident than design, do what I would have done anyway. But I prefer making that choice on my own, depending on the particular circumstances.

-- 
David Kastrup