The first time I tried to use --no-ff I tried to do something like this: git checkout master git commit -a -m'whatever' git commit -a -m'whatever2' git merge --no-ff origin/master and was disappointed when "it didn't work" and git told me there was nothing to do as the branch was up to date. (Which I found a bit confusing.) I realize now my expectations were incorrect, and that the argument to merge needs to resolve to a commit that is ahead of the current commit, and in the above sequence it is the other way around. So to do what I want I can do: git checkout master git checkout -b topic git commit -a -m'whatever' git commit -a -m'whatever2' git checkout master git merge --no-ff topic and iiuir this works because 'master' would be behind 'topic' in this case. But I have a few questions, 1) is there is an argument to feed to git merge to make the first recipe work like the second? And 2) is this asymmetry necessary with --no-ff? More specifically would something horrible break if --no-ff origin/trunk detected that the current branch was ahead of the named branch and "swapped" the implicit order of the two so that the first recipe could behave like the second? Anyway, even if the above makes no sense, would it be hard to make the message provided by git merge in the first recipe a bit more suggestive of what is going on? For instance if it had said "Cannot --no-ff merge, origin/master is behind master" it would have been much more clear what was going on. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
