brian m. carlson wrote: > On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote: > > Marc Branchaud wrote: > > > On 14-04-30 04:14 PM, Felipe Contreras wrote: > > > > 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. > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
