On Fri, Jan 5, 2018 at 2:26 PM, Paul Smith <p...@mad-scientist.net> wrote: > On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote: >> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey <rcdailey.li...@gmail.com> >> wrote: >> > Not sure if this is intended or a bug, but with the following >> > configuration: >> > >> > $ git config --global merge.ff false >> > >> > I am not able to merge my topic branch into master with squash >> > option: >> > >> > $ git checkout master >> > $ git merge --squash topic >> > fatal: You cannot combine --squash with --no-ff. >> > >> > I'm not sure why a non-fast-forward merge would prevent a squash >> > merge, since by its very nature a squashed merge is not a fast >> > forward merge (or maybe it is if you only have one commit). > > Hah! I was just thinking of checking the latest Git RC I built > yesterday to see if this pet peeve of mine has been fixed yet. I guess > not! > >> The easiest way to move forward is probably to pass "--ff" on the >> command line to override the config, when you're using "--squash". > > That's what we always have to do. Very annoying; we use squash-merge > extensively but also want to require ff merge by default. > >> As for why the two aren't allowed together, my assumption would be >> because if you're only squashing a single commit "--squash" and that >> commit is fast-forward from the target, a new commit is not created >> and instead the target branch is fast-forwarded. With "--no-ff", it's >> questionable what "--squash" should do in that case. Fast-forward >> anyway? Rewrite the commit simply to get new committer details and >> SHA-1? > > If it only failed when you were squash-merging a single commit that was > also fast-forwardable, I guess that would be one thing. But even if I > have multiple commits and I want to squash-merge them, which clearly is > a separate operation giving different results, I get this error. > > I don't think Git should try to be clever here (if that's what it's > doing--I always assumed it was just a missing configuration case in the > error check). If I asked for a squash-merge then Git should give me a > squash merge. > > So in answer to your question, --squash should give me a squash merge > and the setting of --ff / --no-ff should be completely ignored, as it's > irrelevant. > > My $0.02.
Seems like --ff works, but is also misleading since in my case (more than one commit) I'm not doing a ff merge and there's no possibility of it. I think your idea of the 2 being distinctly separate makes sense. Basically, --squash takes precedence and if the mechanism to implement squash in certain scenarios (such as single commit) is fast-forward merge, then that decision is made for the user and is no longer something they can control.
