* Can't squash merge with merge.ff set to false @ 2018-01-05 19:59 Robert Dailey 2018-01-05 20:12 ` Bryan Turner 2018-01-06 0:11 ` Jonathan Nieder 0 siblings, 2 replies; 7+ messages in thread From: Robert Dailey @ 2018-01-05 19:59 UTC (permalink / raw) To: Git 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). Is there an issue here? I like fast forward merges to be off by default, since I want to control when they happen. Most of my merges do not use --squash, so I'm catering to the common case. Need advice on how to get past this issue. Thanks in advance. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Can't squash merge with merge.ff set to false 2018-01-05 19:59 Can't squash merge with merge.ff set to false Robert Dailey @ 2018-01-05 20:12 ` Bryan Turner 2018-01-05 20:26 ` Paul Smith 2018-01-06 0:11 ` Jonathan Nieder 1 sibling, 1 reply; 7+ messages in thread From: Bryan Turner @ 2018-01-05 20:12 UTC (permalink / raw) To: Robert Dailey; +Cc: Git On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey <rcdailey.lists@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). > > Is there an issue here? I like fast forward merges to be off by > default, since I want to control when they happen. Most of my merges > do not use --squash, so I'm catering to the common case. > > Need advice on how to get past this issue. Thanks in advance. The easiest way to move forward is probably to pass "--ff" on the command line to override the config, when you're using "--squash". 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? Hope this helps! Bryan Turner ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Can't squash merge with merge.ff set to false 2018-01-05 20:12 ` Bryan Turner @ 2018-01-05 20:26 ` Paul Smith 2018-01-05 20:35 ` Robert Dailey 0 siblings, 1 reply; 7+ messages in thread From: Paul Smith @ 2018-01-05 20:26 UTC (permalink / raw) To: Bryan Turner, Robert Dailey; +Cc: Git On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote: > On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey <rcdailey.lists@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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Can't squash merge with merge.ff set to false 2018-01-05 20:26 ` Paul Smith @ 2018-01-05 20:35 ` Robert Dailey 2018-01-05 20:54 ` Bryan Turner 0 siblings, 1 reply; 7+ messages in thread From: Robert Dailey @ 2018-01-05 20:35 UTC (permalink / raw) To: paul; +Cc: Bryan Turner, Git On Fri, Jan 5, 2018 at 2:26 PM, Paul Smith <paul@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.lists@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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Can't squash merge with merge.ff set to false 2018-01-05 20:35 ` Robert Dailey @ 2018-01-05 20:54 ` Bryan Turner 2018-01-05 21:44 ` Robert Dailey 0 siblings, 1 reply; 7+ messages in thread From: Bryan Turner @ 2018-01-05 20:54 UTC (permalink / raw) To: Robert Dailey; +Cc: paul, Git On Fri, Jan 5, 2018 at 12:35 PM, Robert Dailey <rcdailey.lists@gmail.com> wrote: > On Fri, Jan 5, 2018 at 2:26 PM, Paul Smith <paul@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.lists@gmail.com> wrote: >>> >>> 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 think there's a reasonable argument that having the failure be consistent is easier to reason about, and therefore provides a "better" user experience (to some definition of "better" which all people may not share in common). If the failure was delayed until "git merge --squash" decided it wanted to fast-forward, the failure might seem more arbitrary. >> >> 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. "--ff" doesn't say "git merge" _must_ fast-forward ("--ff-only"); it says that it _can_. At a general level with "--squash", that seems to be exactly correct. A "--squash" merge can create a new commit, or it can fast-forward an existing commit if the situation allows. Based on that, passing "--ff" doesn't seem misleading to me. > 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. 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Can't squash merge with merge.ff set to false 2018-01-05 20:54 ` Bryan Turner @ 2018-01-05 21:44 ` Robert Dailey 0 siblings, 0 replies; 7+ messages in thread From: Robert Dailey @ 2018-01-05 21:44 UTC (permalink / raw) To: Bryan Turner; +Cc: paul, Git On Fri, Jan 5, 2018 at 2:54 PM, Bryan Turner <bturner@atlassian.com> 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Can't squash merge with merge.ff set to false 2018-01-05 19:59 Can't squash merge with merge.ff set to false Robert Dailey 2018-01-05 20:12 ` Bryan Turner @ 2018-01-06 0:11 ` Jonathan Nieder 1 sibling, 0 replies; 7+ messages in thread From: Jonathan Nieder @ 2018-01-06 0:11 UTC (permalink / raw) To: Robert Dailey; +Cc: Git, Paul Smith Hi, Robert Dailey 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 see two issues here: 1. The check and error message really only make sense when you passed --no-ff directly, not implicitly using config. The problem you are running into was presumably introduced when merge.ff was added in v1.7.6-rc0~67^2~1 (2011-05-06). 2. Whether it comes from an alias or config, --no-ff and --squash are not fundamentally incompatible. --no-ff says not to do something and --squash says to do a different thing, so --squash should win. So I suspect that making --squash override --no-ff would be a reasonable behavior. Care to write a patch? Thanks, Jonathan ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-01-06 0:11 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-05 19:59 Can't squash merge with merge.ff set to false Robert Dailey 2018-01-05 20:12 ` Bryan Turner 2018-01-05 20:26 ` Paul Smith 2018-01-05 20:35 ` Robert Dailey 2018-01-05 20:54 ` Bryan Turner 2018-01-05 21:44 ` Robert Dailey 2018-01-06 0:11 ` Jonathan Nieder
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).