Miklos Vajna 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 "users got u
On Mon, Jul 01, 2013 at 08:38:21AM -0700, Junio C Hamano
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 the esta
Michael Haggerty 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 these
> exp
Hi Michael,
On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty
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
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
5 matches
Mail list logo
