Re: Pull is Mostly Evil

From: Richard Hansen <rhansen@bbn.com>
To: Felipe Contreras <felipe.contreras@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Marc Branchaud <marcnarc@xiplink.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Pull is Mostly Evil
Date: Mon, 05 May 2014 01:44:46 -0400	[thread overview]
Message-ID: <5367254E.5030402@bbn.com> (raw)
In-Reply-To: <5366ad66b9a6c_18f9e4b308b8@nysa.notmuch>

On 2014-05-04 17:13, Felipe Contreras wrote:
> Richard Hansen wrote:
>> On 2014-05-04 06:17, Felipe Contreras wrote:
>>> Richard Hansen wrote:
>>>> On 2014-05-03 23:08, Felipe Contreras wrote:
>>>>> It is the only solution that has been proposed.
>>>>
>>>> It's not the only proposal -- I proposed a few alternatives in my
>>>> earlier email (though not in the form of code), and others have too.  In
>>>> particular:
>>>>
>>>>   * create a new 'git integrate' command/alias that behaves like 'git
>>>>     pull --no-ff'
>>>
>>> Yeah but that's for a different issue altogheter. I doesn't solve the
>>> problems in 1. nor 2. nor 3.
>>
>> 'git integrate' would handle usage cases #2 (update a published branch
>> to its "parent" branch) and #3 (integrate a completed task into the main
>> line of development),
> 
> But these cases are completely different. One should reverse the
> parents, the other one not.

No -- for both #2 and #3 I want the remote branch to be merged into the
local branch.

In the example I gave for use case #2, foo is a local branch with
origin/foo as the configured upstream and origin/foo was forked off of
origin/master.  Someone pushed new stuff to origin/master, and the user
wants the new stuff to also be in origin/foo.  So the user does this:

  git checkout foo
  git pull --ff-only  # this is use case #1
  git pull origin master  # this is use case #2
  git push

The merge commit created by 'git pull origin master' should have
origin/master as the second parent, not the first.

-Richard