Lars Hjemli <hjemli@gmail.com> wrote:
quoted text
> 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.

quoted text
> ---
> 
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html