[Cc'd Eric since he's the expert on git-svn] On 9/17/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 - 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
