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