Re: [PATCH] git-merge: add option --no-ff
- From
- Lars Hjemli <hjemli@gmail.com>
- Date
- Sep 18, 2007, 08:02 UTC
- Message-ID
- <8c5c35580709180102l10e89094tab801cd5742c6415@mail.gmail.com>
- In-Reply-To
- <7v4phsxy55.fsf@gitster.siamese.dyndns.org>
On 9/18/07, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> "Lars Hjemli" <hjemli@gmail.com> writes: > > > On 9/18/07, Eric Wong <normalperson@yhbt.net> 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.