Hi Michael, On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > On 07/01/2013 09:01 AM, Miklos Vajna wrote: > > 1347483 (Teach 'git merge' and 'git pull' the option --ff-only, > > 2009-10-29) says this is not allowed, as they contradict each other. > > > > However, --ff-only is about asserting the input of the merge, and > > --no-ff is about instructing merge to always create a merge commit, i.e. > > it makes sense to use these options together in some workflow, e.g. when > > branches are integrated by rebasing then merging, and the maintainer > > wants to be sure the branch is rebased. > > That is one interpretation of what these options should mean, and I > agree that it is one way of reading the manpage (which says > > --ff-only:: > Refuse to merge and exit with a non-zero status unless the > current `HEAD` is already up-to-date or the merge can be > resolved as a fast-forward. > > ). However, I don't think that the manpage unambiguously demands this > interpretation, and that (more importantly) most users would be very > surprised if --ff-only and --no-ff were not opposites. Yes, I agree that that's an unfortunate naming. --ff and --no-ff is the opposite of each other, however --ff-only is independent, and I would even rename it to something like --ff-input-only -- but I don't think it's worth to do so, seeing the cost of it (probably these options are used by scripts as well). > How does it hurt? If I have configuration value merge.ff set to "only" > and run "git merge --no-ff" and then I merge a branch that *cannot* be > fast forwarded, the logic of your patch would require the merge to be > rejected, no? But I think it is more plausible to expect that the > command line option takes precedence. Hmm, I did not remember that actually merge.ff even uses the same configuration slot for these switches. :-( Yes, that would make sense to fix, once the switches can be combined. Maybe merge.ff and merge.ff-only? > In my opinion, your use case shouldn't be supported by the command > because (1) it is confusing, I don't see why it would be confusing. I think using these two options together is one way to try to get the benefits of both rebase (cleaner history) and merge (keeping the history of which commits came from a given merge). > (2) it is not very common, Hard to argue that argument. :-) No idea what counts as common, my motivation is that some projects (e.g. syslog-ng) integrate *every* feature branch this way, and doing this "manually" (as in indeed manually or by using a helper script) seems suboptimal, when the support for this is already mostly in merge.c, just disabled. > easy to work around: > > if git merge-base --is-ancestor HEAD $branch > then > git merge --no-ff $branch > else > echo "fatal: Not possible to fast-forward, aborting." > exit 1 > fi Right, that's indeed a viable workaround for the problem. Miklos
Attachment:
signature.asc
Description: Digital signature