On Fri, Jan 5, 2018 at 2:54 PM, Bryan Turner <bturner@xxxxxxxxxxxxx> wrote: > The two _aren't_ distinctly separate, though. "git merge --squash > --ff-only" has very different semantics to "git merge --squash --ff", > in that it will only create a new squashed commit (or fast-forward a > single commit) if the incoming commit(s) are fast-forward from the > target. So there _is_ a setting for the fast-forward mode (given > "--ff", "--ff-only", and "--no-ff" are a tri-state switch, and > therefore comprise a single setting) that does impact squashing. That feels really contrived to me though. For example, when I'm asking to squash I don't really care about fast forward in that case. Squashing means I'm expecting a possibly completely new commit with my collective changes. If I only had one commit on my branch, likely I'd be aware of that, and would do a fast forward merge or something. I think the difference here is mind set. And maybe this is just me, but the mentality when I choose --squash means I want nothing to do with fast-foward. I don't care about it affecting the operation. If a fast-foward happens to be the end result, I still don't care. Git made that decision for me. And all I want is the end result: A single commit.
