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

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

[Cc'd Eric since he's the expert on git-svn]

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

Show 17 quoted lines

> Hi,
>
> On Mon, 17 Sep 2007, Lars Hjemli wrote:
>
> > When 'git-svn dcommit' decides which commits it should push back
> > subversion, it scans the output from 'git-log --first-parent HEAD'
> > looking for embedded 'git-svn-id' lines. These lines contain the url
> > of the upstream subversion repository + the subversion revision
> > number.
>
> > So the problem with fast-forward merges of subversion branches is that
> > the output from 'git-log --first-parent HEAD' will show commits from the
> > wrong subversion branch (the fast-forwarded commits).
>
> Ah, I think I know what you're trying to get at.  But "git svn fetch &&
> git rebase git-svn" might be a better approach than "git svn fetch && git
> merge --no-ff git-svn", no?

If I'm understanding you right: no. After a rebase, the commits would be ignored by git-svn when looking for the subversion upstream branch (since the commit SHA1's would no longer match the ones stored in git-svn's rev_db), but the subversion history would look like 'cherry-picked n commits from merged branch' after dcommit.

-- 
larsh