On 9/18/07, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Lars Hjemli" <hjemli@xxxxxxxxx> writes: > > > On 9/18/07, Eric Wong <normalperson@xxxxxxxx> wrote: > >> Would automatically enabling --no-ff when it detects merging of two (or > >> more) SVN branches be a good thing? > > > > I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner. > > That unfortunately does not solve the problem. > The problem we're trying to solve is to somehow avoid fast-forward merges between git-svn branches, right? I don't think it's a big issue in itself. If a fast-forward occurs, what will happen is basically that git-svn will guess the wrong upstream branch and then proceed to do nothing [1]. The user can always recover from this state with 'git-reset' and 'git-merge --no-ff'. So I think the result of a fast-forward merge between git-svn branches is annoying, but not fatal [2]. But a closely related issue is that git-svn shouldn't dcommit to the wrong upstream (even in the case of a fast-forward merge). We need a way to explicitly show the link between the local and remote svn branch (something like .git/config perhaps). -- larsh [1] If the merged-in branch had local commits they will be 'dcommited' to the correct upstream of the merged-in branch, which isn't to bad [2] if git-svn could be fixed to handle even the ff case, someone could actually prefer to get the 'cherry-picked' history in subversion. I don't, hence my --no-ff patch, but I'm not at all certain this should be _forced_ on git-svn branches. - 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
