Re: [PATCH] git-merge: add option --no-ff

From: Eric Wong <normalperson@yhbt.net>
Date: Sep 18, 2007, 00:50 UTC
Message-ID: <20070918005013.GA6368@muzzle>
In-Reply-To: <11900461843997-git-send-email-hjemli@gmail.com>

Lars Hjemli <hjemli@gmail.com> wrote:

Show 13 quoted lines

> This option forces fast-forward merges to create a "true" merge commit,
> i.e. a commit with multiple parents.
> 
> Although a fast-forward merge would normally be the right thing to do with
> git branches, it is suboptimal when operating on git-svn branches since it
> makes 'git-svn dcommit' fail to recognize the correct upstream subversion
> branch. But performing such a merge with --no-ff specified will both make
> git-svn dcommit recognize the correct upstream and create the logically
> correct history in subversion (the merge performed in git will be recorded
> as a single revision in subversion, not as a series of revisions seemingly
> cherry-picked from the merged branch).
> 
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>

Would automatically enabling --no-ff when it detects merging of two (or more) SVN branches be a good thing? We can add scripting support to git-svn for detecting if any given commit is really from SVN or not. Then we could do something like this in git-merge

---------------------------- 8< --------------------------------
if git-svn test-svn-commits "$@"
then
	no_ff=t
	no_fast_forward_strategies=$all_strategies
fi
---------------------------- 8< --------------------------------

It'd probably prevent a lot of users from shooting themselves in the foot if they forget to read or learn about the --no-ff option.

> ---
> 
> When updating git-svn.txt, I noticed that we might want to update the 
> section "DESIGN PHILOSOPHY". Eric?

Yeah.  That's very much out of date.  I'll update it in a bit.

-- 
Eric Wong