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

From: Lars Hjemli <hjemli@gmail.com>
Date: Sep 17, 2007, 15:17 UTC
Message-ID: <8c5c35580709170817s467fa7dv375952f872bba0e3@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0709171603090.28586@racer.site>

On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 28 quoted lines

> Hi,
>
> On Mon, 17 Sep 2007, Lars Hjemli wrote:
>
> > On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > But then, I do not use svn branches here, and that might be the problem?
> >
> > Probably. The case I'm trying to solve is:
> >   -git-svn branch A is merged into git-svn branch B
> >   -A is a fast-forward of B
> >
> > This might look unrealistic, but it happened to me today when I wanted
> > to merge a feature-branch into a relase-branch. The release-branch had
> > previously been merged into the feature-branch (to get a few
> > bugfixes), but the release-branch had not changed since this merge. So
> > when merging the feature-branch into the release-branch it just
> > fast-forwarded, leaving me with an 'un-dcomittable' release-branch. I
> > obviously could have done the merge in subversion (haha!), but doing
> > it in git preserves the correct history.
> >
> > Btw: I have redone the merge with --no-ff, and dcommit then worked
> > like a charm ;-)
>
> Yep, I can see that now.
>
> But maybe there is a better method to detect the latest svn id, by not
> only looking up the svn ids, but making sure that they come from the
> current branch?

Actually, I looked into this last week (my --upstream rants), and I guess git-svn could use the --track information in .git/config (if present) as a sanity check when resolving the upstream. But this would still make the subversion history look like crap after a fast-forward merge of the kind I was messing with today. It was logically a merge, but if dcommit had worked 'correctly' it would have created ~150 new revisions in the release-branch instead of the single merge commit.

> (I'm happily unaware of git-svn's internals, so that might not be
> feasible... But I think that it might be worth fixing that for the git-svn
> idiot like me, since I would never guess that I have to specify --no-ff
> when working on branches that come from git-svn...)

In the normal cases there is no need for --no-ff, only in degenerated cases like the one I stumbled upon today ;-)

I'll resend the patch with a link from merge-options.txt to git-svn.txt and try to describe (in git-svn.txt) when to use --no-ff.

-- 
larsh