From: Lars Hjemli Date: Mon, 17 Sep 2007 13:38:01 GMT Subject: Re: [PATCH] git-merge: add option --no-ff Message-ID: <8c5c35580709170638mc0c8279pa86d71bd79fd3084@mail.gmail.com> In-Reply-To: [Cc'd Eric since he's the expert on git-svn] On 9/17/07, Johannes Schindelin wrote: > 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