On 9/17/07, Andreas Ericsson <ae@xxxxxx> wrote: > Lars Hjemli wrote: > > This new option forces all merges to create a "true" merge commit, i.e. a > > commit with multiple parents. > > > > Although a fast-forward would normally be The Right Thing, it isn't when the > > branches to be merged originated in subversion and the merge commit will > > be pushed back by means of 'git svn dcommit'. In these cases, a fast- > > forward merge simply will not work. > > > > If there is no `-s` option, a built-in list of strategies > > is used instead (`git-merge-recursive` when merging a single > > head, `git-merge-octopus` otherwise). > > + > > +--no-ff:: > > + Force the creation of a merge commit even when the merge would > > + have resolved as a fast-forward operation. > > + Although a fast-forward would normally be The Right Thing, it isn't when the > + branches to be merged originated in subversion and the merge commit will > + be pushed back by means of 'git svn dcommit'. In these cases, a fast- > + forward merge simply will not work. > > Otherwise someone will sit down and try to figure out why this is necessary. True. > I'm having trouble understanding why this is needed, but I'll take your word > for it ;-) I'll try to explain: 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). This could maybe be fixed in git-svn if it learned a different way of discovering the upstream subversion branch, but then it would make git-svn commit n revisions to subversion (again, the fast-forwarded commits) instead of a single merge-commit. This would look (in subversion) like a series of n cherry-picks from the merged branch. Btw: maybe the --no-ff section in merge-options.txt could just link to git-svn.txt, which in turn could have some lengthy explanation about merge --no-ff/dcommit behaviour? -- 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
