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
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
Hi Michael,
On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty
mhag...@alum.mit.edu 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,
Michael Haggerty mhag...@alum.mit.edu writes:
So I think that command invocations with more than one of {--ff,
--no-ff, --ff-only} should respect the last option listed rather
than complaining about cannot combine options.
If I find the time (unlikely) I might submit a patch to implement
On Mon, Jul 01, 2013 at 08:38:21AM -0700, Junio C Hamano gits...@pobox.com
wrote:
As to --no-ff vs --ff-only, --ff-only has always meant only
fast-forward updates are allowed. We do not want to create a merge
commit with this operation. I do agree with you that the proposed
patch changes
Miklos Vajna vmik...@suse.cz writes:
OK, so if I get it right, the problem is that users got used to
that the --ff-only not only means a precondition for the merge,
but also means either don't create a merge commit or fail, while
my patch would change this second behaviour.
It is not just
6 matches
Mail list logo
