Re: Pull is Evil

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> 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.

I asked the simple uncontroversial question as a rhetorical aid. I hoped
I would get the obvious answer, but I didn't even get that, so what hope
is there of convincing these people of the one that needs real pondering?

> 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?

That's right, but we are discussing the default behavior of `git pull`,
which if we agree has no problems when the ff is a) possible, and b)
desirable, the problems must come when either one of those is not met.

 a) If the fast-forward is not possible, that creates problems, because
    a real merge might happen, and it's not desirable. However, if we
    don't allow real merges to happen by default this couldn't be a
    problem.

 b) If the fast-forward is not desirable, then the user wouldn't be
    running `git pull`, would be running `git pull --no-ff`.

In other words, after the proposed changes `git pull` by default would
have no issues.

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

No, it doesn't hold. As I said, if we change the default the fact that
it's not possible is not an issue.

The only problem would be when it's not desirable, however, that's a
problem of the user's ignorance, and the failure of the project's
policity to communicate clearly to him that he should be running
`git merge --no-ff`. There's absolutely nothing we can do to help him.

The only thing we could do is not allow fast-forward merges either, in
which case `git pull` becomes a no-op that can't possibly do anything
ever.

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

First of all this use-case is not realistic. The moment he merges a
developer branch, hes maintenance and the probject's diverge, and all
the pulls after that cannot be fast-forward.

It's pointless to add something that just doesn't happen. It will be
possible to do the fast-forward merges only early on the life of this
branch, not afterwards. For this short period of time he can just simply
use his fingers to type `git merge --no-ff`.

-- 
Felipe Contreras