Gerrit Pape <pape@xxxxxxxxxxx> writes: > git-merge used to use either the --squash,--no-squash, --no-ff,--ff, > --no-commit,--commit option, whichever came last in the command line. > This lead to some un-intuitive behavior, having > > git merge --no-commit --no-ff <branch> > > actually commit the merge. Now git-merge respects --no-commit together > with --no-ff, as well as other combinations of the options. However, > this broke a selftest in t/t7600-merge.sh which expected to have --no-ff > completely override the --squash option, so that > > git merge --squash --no-ff <branch> > > fast-forwards, and makes a merge commit; now it prepares a squash ... Both make sense when they make sense (i.e. if you and the other side are not fast-forward nor up-to-date and need a real merge). > ... Combining --squash with --no-ff doesn't seem to make sense Yeah, I think forbidding this combination would make much more sense. The former asks there be _no_ merge (the user does not want to have a merge ever), while the other one asks to create a merge even when there is no need to (the user does want a merge). Are there other combinations that we should forbid? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
