Re: Pull is Evil

[Junio C Hamano <gitster@pobox.com>]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> brian m. carlson wrote:
>> ..
>> At work, we have a workflow where we merge topic branches as
>> non-fast-forward, so that we have a record of the history (including who
>> reviewed the code), but when we want to just update our local branches,
>> we always want fast-forward:
>> 
>>   git checkout maintenance-branch
>>   # Update our maintenance branch to the latest from the main repo.
>>   git pull --ff-only
>>   git pull --no-ff developer-remote topic-branch
>>   git push main-repo HEAD
>> 
>> So there are times when fast-forward merges are the right thing, and
>> times when they're not, and as you can see, this depends on context and
>> isn't per-repository.
>
> That's not what I asked.
>
> I didn't ask you if fast-forward merges were the right thing to do in
> every situation.
>
> I asked you, *when* people do a fast-forward merge (that is; when it's
> possible and desirable), what are the problems that a fast-forward merge
> causes?

But then I think you asked a wrong question.  The opposite case of
the question tells me what is wrong in it:

    When people do a real merge (that is: when it's possible and
    desirable), there is no reason to forbid 'git pull' from creating a
    real merge.  What are the problems that a real merge causes under
    that condition?

By definition, because of "when it's possible and DESIRABLE" part,
the answer is "absolutely zero".  That is not an interesting
question, is it?

My reading of the design of the "let's forbid non-ff merge when
people do 'git pull'" is based on this reasonong:

 - Most people are not integrators, and letting "git pull" run on
   their work based on a stale upstream to sync with an updated
   upstream would create a merge in a wrong direction and letting
   user continue on it.  We need to have a way to prevent this.

 - Forbid "git pull" when the HEAD is based on a stale upstream,
   i.e. the pull does not fast-forward.  Integrators that would want
   to _allow_ real merges may be inconvenienced so we will give a
   configuration to let them say that with pull.mode=merge.

 - We do not forbid "git pull" if the pull will fast-forward.  We do
   not do anything for that case, because everybody will accept
   fast-forward, whether he is a contributor or an integrator.

Doesn't Brian's case show the justification "because everybody will
accept fast-forward" does not hold?  It shows that the user do not
necessarily know when it's possible and DESIRABLE, and updating the
command is about helping people avoid an action that may not be
desirable in the end.

Brian needs a way to make sure he fast-forwards when pulling the
project's maintenance-branch into his maintenance-branch, and also
he does *not* fast-forward when pulling developer's fix branch into
that same maintenance-branch of his.  So neither pull.mode nor
branch.*.pullmode would help him and the example may show we need a
bit more work to help that case, no?