On 18 April 2016 at 16:26, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > > > The command only works as expected when also adding the --no-ff flag. > > Then you need to fix your expectations ;-)
I *think* the core of this problem is that the intent of the end-user does not align with the command options available. In this use case (as far as I can tell), the user wants to see what the result of a merge from somewhere else will look like, without changing their HEAD. While you are correct in saying a fast-forward does not create any new commits, for the user it certainly looks like a whole slew of new commits have been added. Moreover, the nature of the option means that the user has to investigate if the merge is a fast-forward in order to know what the outcome of the command will be. If the merge is a fast-forward, --no-commit has no effect on the outcome. If the merge is not a fast-forward, --no-commit has a huge effect on the outcome. If I see a --no-commit option, as an inexperienced user, I would be quite surprised to find my HEAD changed after using it. It would be far more intuitive, for that user, for --no-commit to imply --no-ff however I suspect that such a change may well cause more problems then it fixes. What I wonder is, in what situation is the current behaviour is desirable? While I agree that the option works as designed, I think its behaviour is more surprising to the end user then it should be. Regards, Andrew Ardill -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
