Thread (26 messages) 26 messages, 8 authors, 2016-06-15

Re: Pull is Evil

From: Felipe Contreras <hidden>
Date: 2016-06-15 23:00:57

Possibly related (same subject, not in this thread)

brian m. carlson wrote:
On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:
quoted
Marc Branchaud wrote:
quoted
On 14-04-30 04:14 PM, Felipe Contreras wrote:
quoted
What is wrong when `git pull` merges a fast-forward?
Nothing.  Everything.  It depends.
It depends on what? I don't see how a fast-forward `git pull` could
possibly have any trouble.
quoted
quoted
The problems with `git pull` come when you can't do a fast-forward merge, right?
Some of them, maybe most of them.
Name one problem with a fast-forward merge.
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?

I tired of waiting, so I'll answer for you: there are absolutely no
problems. The problems are only on non-fast-forward merges, and we have
a solution.

-- 
Felipe Contreras
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help