{"thread":{"id":"10087","subject":"git-svn merge helper","startedAt":"2007-09-30T11:05:50Z","lastAt":"2007-10-03T11:40:05Z","messageCount":10,"participants":["Björn Steinbrink","Benoit SIGOURE","Steven Walter","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"54403","messageId":"20070930110550.GA4557@atjola.homenet","threadId":"10087","inReplyTo":null,"subject":"git-svn merge helper","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-09-30T11:05:50Z","receivedAt":"2007-09-30T11:05:50Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"Hi,\n\nI recently discovered git-svn and absolutey love it. One thing that I'm\nmissing though, is an equivalent of \"svn merge\" for merging between svn\nremotes, to support the SVN way of using \"squashed\" merges, where you\njust note the merge meta-data in the commit message. \"git merge\" didn't\nwork for me (and probably isn't expected to work) to merge between two\nsvn branches, so I've resorted to cherry-picking the required commits\none by one into a temporary branch and then squashing them together by\ndoing a --squash merge with a second temporary branch (as in [1]).\n\nOf course that becomes extremely annoying if there are like 200\ncommits to merge, so I came up with the following script to help me.\nIt does just what I described above, but automated. Usage is like this:\n\ngit-svn-merge trunk 123 543\n\nWhich does the same as \"svn merge -r123:543 trunk-url\", except for being\nincremental (ie. no huge one-time patch, eventually causing a massive\nset of conflicts) and often faster.\n\nIn case of conflicts, it bails out and let's you fix them. Then you can\njust re-run it with the same parameters again, as it automatically\ndetermines where to start cherry-picking if you're currently on the\nmerge branch.\n\nIt's neither complete nor nice to look at, but it more or less gets the\njob done, so I thought I'll just post it here, maybe someone picks it up\nand brings it into shape.\n\nThanks,\nBjörn\n\n[1] http://cheat.errtheblog.com/s/gitsvn/\n\n\n#!/bin/sh\n\nBRANCH=$(git branch | grep \\* | cut -d ' ' -f2)\n\nSTART=$(git svn find-rev r$2 $1)\nEND=$(git svn find-rev r$3 $1)\n\nif echo $BRANCH | grep -q svnmerge/\nthen\n\tSTART=$(git svn find-rev r$(git svn find-rev HEAD) $1)\nelse\n\tgit checkout -b svnmerge/$BRANCH\nfi\n\nfor HASH in $(git log --pretty=format:%H --reverse $START..$END)\ndo\n\tgit cherry-pick $HASH || exit\ndone\n\ngit checkout $BRANCH\ngit checkout -b svnmerge/$BRANCH-squashed\ngit merge --squash svnmerge/$BRANCH\ngit commit -m \"Merged changes from revisions $2-$3 from $1 into $BRANCH.\"\n"},{"id":"54413","messageId":"1EF130A4-3CC7-4A42-9166-3539D9A38828@lrde.epita.fr","threadId":"10087","inReplyTo":"20070930110550.GA4557@atjola.homenet","subject":"Re: git-svn merge helper","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-09-30T14:15:49Z","receivedAt":"2007-09-30T14:15:49Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Sep 30, 2007, at 1:05 PM, Björn Steinbrink wrote:\n\n> Hi,\n>\n> I recently discovered git-svn and absolutey love it. One thing that  \n> I'm\n> missing though, is an equivalent of \"svn merge\" for merging between  \n> svn\n> remotes, to support the SVN way of using \"squashed\" merges, where you\n> just note the merge meta-data in the commit message. \"git merge\"  \n> didn't\n> work for me (and probably isn't expected to work) to merge between two\n> svn branches, so I've resorted to cherry-picking the required commits\n> one by one into a temporary branch and then squashing them together by\n> doing a --squash merge with a second temporary branch (as in [1]).\n\nI fail to see why you'd want to reproduce the broken behavior of svn  \nmerge.  Anyways, git-svn is a great way to merge SVN branches,  \nunfortunately it can't detect when merges happened on the SVN side.   \nI think you can use it nevertheless by manually adding a graft at the  \nlast merge point, which would help you merging the right revisions  \nwithout having to specify what needs to be merged (unless someone  \nmade another merge on the SVN side, in which case you need to update  \nyour graft).\n\nCheers,\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"54449","messageId":"20071001025059.GA29323@atjola.homenet","threadId":"10087","inReplyTo":"1EF130A4-3CC7-4A42-9166-3539D9A38828@lrde.epita.fr","subject":"Re: git-svn merge helper","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-10-01T02:50:59Z","receivedAt":"2007-10-01T02:50:59Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.09.30 16:15:49 +0200, Benoit SIGOURE wrote:\n> On Sep 30, 2007, at 1:05 PM, Björn Steinbrink wrote:\n>\n>> Hi,\n>>\n>> I recently discovered git-svn and absolutey love it. One thing that I'm\n>> missing though, is an equivalent of \"svn merge\" for merging between svn\n>> remotes, to support the SVN way of using \"squashed\" merges, where you\n>> just note the merge meta-data in the commit message. \"git merge\" didn't\n>> work for me (and probably isn't expected to work) to merge between two\n>> svn branches, so I've resorted to cherry-picking the required commits\n>> one by one into a temporary branch and then squashing them together by\n>> doing a --squash merge with a second temporary branch (as in [1]).\n>\n> I fail to see why you'd want to reproduce the broken behavior of svn merge. \n>  Anyways, git-svn is a great way to merge SVN branches, unfortunately it \n> can't detect when merges happened on the SVN side.  I think you can use it \n> nevertheless by manually adding a graft at the last merge point, which \n> would help you merging the right revisions without having to specify what \n> needs to be merged (unless someone made another merge on the SVN side, in \n> which case you need to update your graft).\n\nThen how does that work? The manpage explicitly says that I should not\nuse git-{pull,merge} on branches I want to dcommit from. And a trivial\ntest immediately got the expected effect of git-svn trying to commit to\ntrunk instead of the branch.\n\nThanks,\nBjörn\n"},{"id":"54455","messageId":"0D8A7A3C-8F51-482D-9229-29ADC9585760@lrde.epita.fr","threadId":"10087","inReplyTo":"20071001025059.GA29323@atjola.homenet","subject":"Re: git-svn merge helper","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-10-01T07:56:21Z","receivedAt":"2007-10-01T07:56:21Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Oct 1, 2007, at 4:50 AM, Björn Steinbrink wrote:\n\n> On 2007.09.30 16:15:49 +0200, Benoit SIGOURE wrote:\n>> On Sep 30, 2007, at 1:05 PM, Björn Steinbrink wrote:\n>>\n>>> Hi,\n>>>\n>>> I recently discovered git-svn and absolutey love it. One thing  \n>>> that I'm\n>>> missing though, is an equivalent of \"svn merge\" for merging  \n>>> between svn\n>>> remotes, to support the SVN way of using \"squashed\" merges, where  \n>>> you\n>>> just note the merge meta-data in the commit message. \"git merge\"  \n>>> didn't\n>>> work for me (and probably isn't expected to work) to merge  \n>>> between two\n>>> svn branches, so I've resorted to cherry-picking the required  \n>>> commits\n>>> one by one into a temporary branch and then squashing them  \n>>> together by\n>>> doing a --squash merge with a second temporary branch (as in [1]).\n>>\n>> I fail to see why you'd want to reproduce the broken behavior of  \n>> svn merge.\n>>  Anyways, git-svn is a great way to merge SVN branches,  \n>> unfortunately it\n>> can't detect when merges happened on the SVN side.  I think you  \n>> can use it\n>> nevertheless by manually adding a graft at the last merge point,  \n>> which\n>> would help you merging the right revisions without having to  \n>> specify what\n>> needs to be merged (unless someone made another merge on the SVN  \n>> side, in\n>> which case you need to update your graft).\n>\n> Then how does that work? The manpage explicitly says that I should not\n> use git-{pull,merge} on branches I want to dcommit from. And a trivial\n> test immediately got the expected effect of git-svn trying to  \n> commit to\n> trunk instead of the branch.\n\nAh, yes, you're right.  Well, this will work the day we can pass an  \noption to git-svn dcommit to tell it where the commit must be sent.\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"54611","messageId":"20071002211400.GA992@atjola.homenet","threadId":"10087","inReplyTo":"8c5c35580710010113v7d4ad14bt129b7cb12d8f4fb8@mail.gmail.com","subject":"Re: git-svn merge helper","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-10-02T21:14:00Z","receivedAt":"2007-10-02T21:14:00Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.10.01 10:13:45 +0200, Lars Hjemli wrote:\n> On 10/1/07, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:\n> > On Oct 1, 2007, at 4:50 AM, Björn Steinbrink wrote:\n> > > Then how does that work? The manpage explicitly says that I should not\n> > > use git-{pull,merge} on branches I want to dcommit from. And a trivial\n> > > test immediately got the expected effect of git-svn trying to\n> > > commit to\n> > > trunk instead of the branch.\n> >\n> > Ah, yes, you're right.  Well, this will work the day we can pass an\n> > option to git-svn dcommit to tell it where the commit must be sent.\n> >\n> \n> This is fixed in the latest version of git-svn (yet to be released).\n> There is no need for an extra option, git-svn dcommit now handles\n> merges between subversion branches correctly.\n\nThanks, but there's still a case that fails.\n\nOne common pattern in SVN is to have the feature branch following the\ntrunk. In git terms, that would mean that the feature branch is\ncontinually rebased onto the HEAD of the HEAD AFAICT (although SVN of\ncourse cannot represent that). The problem with that is, that git\ndoesn't create a merge commit in that case and git-svn gets confused\nagain.\n\ngit checkout mybranch\ngit merge master # Creates a merge commit\ngit checkout master\ngit merge mybranch # Does just fast forward\n\nIs there anyway to force a merge commit or some other work around?\n\nThanks,\nBjörn\n"},{"id":"54617","messageId":"20071002220458.GA21038@dervierte","threadId":"10087","inReplyTo":"20071002211400.GA992@atjola.homenet","subject":"Re: git-svn merge helper","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2007-10-02T22:04:58Z","receivedAt":"2007-10-02T22:04:58Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Tue, Oct 02, 2007 at 11:14:00PM +0200, Björn Steinbrink wrote:\n> One common pattern in SVN is to have the feature branch following the\n> trunk. In git terms, that would mean that the feature branch is\n> continually rebased onto the HEAD of the HEAD AFAICT (although SVN of\n> course cannot represent that). The problem with that is, that git\n> doesn't create a merge commit in that case and git-svn gets confused\n> again.\n> \n> git checkout mybranch\n> git merge master # Creates a merge commit\n> git checkout master\n> git merge mybranch # Does just fast forward\n> \n> Is there anyway to force a merge commit or some other work around?\n\nWhen I want to do something like this, I go about it one of two ways.\nThe first option is to simply rebase mybranch onto master.  Since my\nfeature branches are not usually published, there is no problem\nrewinding them.  That may not be an option for you, however.\n\nThe other option is to have a \"build\" branch.  By example:\n\ngit checkout build\ngit reset --hard master\ngit merge mybranch\nmake\n\nIn that way, I have branch with the latest changes from head and the\nchanges from mybranch together.  The downside to this method is that you\nmay have to repeated resolve merges.  Despite the downsides, I find\nthese two methods to work quite well.\n-- \n-Steven Walter <stevenrwalter@gmail.com>\n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n   -Robert Heinlein\n"},{"id":"54620","messageId":"20071002223813.GA3152@atjola.homenet","threadId":"10087","inReplyTo":"20071002220458.GA21038@dervierte","subject":"Re: git-svn merge helper","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-10-02T22:38:13Z","receivedAt":"2007-10-02T22:38:13Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.10.02 18:04:58 -0400, Steven Walter wrote:\n> On Tue, Oct 02, 2007 at 11:14:00PM +0200, Björn Steinbrink wrote:\n> > One common pattern in SVN is to have the feature branch following the\n> > trunk. In git terms, that would mean that the feature branch is\n> > continually rebased onto the HEAD of the HEAD AFAICT (although SVN of\n> > course cannot represent that). The problem with that is, that git\n> > doesn't create a merge commit in that case and git-svn gets confused\n> > again.\n> > \n> > git checkout mybranch\n> > git merge master # Creates a merge commit\n> > git checkout master\n> > git merge mybranch # Does just fast forward\n> > \n> > Is there anyway to force a merge commit or some other work around?\n> \n> When I want to do something like this, I go about it one of two ways.\n> The first option is to simply rebase mybranch onto master.  Since my\n> feature branches are not usually published, there is no problem\n> rewinding them.  That may not be an option for you, however.\n\nUnfortunately not, the branch in question is required to be in the SVN\nrepository.\n\n> The other option is to have a \"build\" branch.  By example:\n> \n> git checkout build\n> git reset --hard master\n> git merge mybranch\n> make\n> \n> In that way, I have branch with the latest changes from head and the\n> changes from mybranch together.  The downside to this method is that you\n> may have to repeated resolve merges.  Despite the downsides, I find\n> these two methods to work quite well.\n\nThanks, but it makes no difference here, it stil results in a fast\nforward. This is a small test case which exhibits the behaviour and\nmatches my current workflow with git-svn (except for the dcommits):\n\ngit init\necho Hi > file1; git add file1; git commit -m file1\ngit checkout -b branch\necho Hi > file2; git add file2; git commit -m file2\ngit checkout master\necho Hi > file3; git add file3; git commit -m file3\ngit checkout branch\ngit merge master\n\n# Then I'd normally do the following which causes a fast forward\n#git checkout master\n#git merge branch\n\n# Now I tried this, which also results in a fast-forward:\ngit checkout -b merge\ngit reset --hard master\ngit merge branch\n\n\nAnything I'm missing?\n\nThanks,\nBjörn\n"},{"id":"54632","messageId":"20071003004252.GA28495@dervierte","threadId":"10087","inReplyTo":"20071002223813.GA3152@atjola.homenet","subject":"Re: git-svn merge helper","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2007-10-03T00:42:52Z","receivedAt":"2007-10-03T00:42:52Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Wed, Oct 03, 2007 at 12:38:13AM +0200, Björn Steinbrink wrote:\n> > The other option is to have a \"build\" branch.  By example:\n> > \n> > git checkout build\n> > git reset --hard master\n> > git merge mybranch\n> > make\n> > \n> > In that way, I have branch with the latest changes from head and the\n> > changes from mybranch together.  The downside to this method is that you\n> > may have to repeated resolve merges.  Despite the downsides, I find\n> > these two methods to work quite well.\n> \n> Thanks, but it makes no difference here, it stil results in a fast\n> forward. This is a small test case which exhibits the behaviour and\n> matches my current workflow with git-svn (except for the dcommits):\n> \n> git init\n> echo Hi > file1; git add file1; git commit -m file1\n> git checkout -b branch\n> echo Hi > file2; git add file2; git commit -m file2\n> git checkout master\n> echo Hi > file3; git add file3; git commit -m file3\n> git checkout branch\n> git merge master\n> \n> # Then I'd normally do the following which causes a fast forward\n> #git checkout master\n> #git merge branch\n> \n> # Now I tried this, which also results in a fast-forward:\n> git checkout -b merge\n> git reset --hard master\n> git merge branch\n\nI believe you misunderstood my suggestion.  In using a \"build\" branch,\nyou would not merge master into branch, as you did above.  Instead, you\nwould create a third, unpublished branch to hold the merge.\n\nAt the same time, I have a slightly better understanding of what it is\nyou're trying to do.  If you are trying to keep up an SVN-like workflow\n(namely pulling changes from trunk into a branch from time to time),\nthen my solution probably isn't suitable for you.  However, you might\nconsider why you actually /need/ to do that, outside of SVN convention.\n-- \n-Steven Walter <stevenrwalter@gmail.com>\n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n   -Robert Heinlein\n"},{"id":"54636","messageId":"20071003010233.GA8610@atjola.homenet","threadId":"10087","inReplyTo":"20071003004252.GA28495@dervierte","subject":"Re: git-svn merge helper","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-10-03T01:02:33Z","receivedAt":"2007-10-03T01:02:33Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.10.02 20:42:52 -0400, Steven Walter wrote:\n> On Wed, Oct 03, 2007 at 12:38:13AM +0200, Björn Steinbrink wrote:\n> > > The other option is to have a \"build\" branch.  By example:\n> > > \n> > > git checkout build\n> > > git reset --hard master\n> > > git merge mybranch\n> > > make\n> > > \n> > > In that way, I have branch with the latest changes from head and the\n> > > changes from mybranch together.  The downside to this method is that you\n> > > may have to repeated resolve merges.  Despite the downsides, I find\n> > > these two methods to work quite well.\n> > \n> > Thanks, but it makes no difference here, it stil results in a fast\n> > forward. This is a small test case which exhibits the behaviour and\n> > matches my current workflow with git-svn (except for the dcommits):\n> > \n> > git init\n> > echo Hi > file1; git add file1; git commit -m file1\n> > git checkout -b branch\n> > echo Hi > file2; git add file2; git commit -m file2\n> > git checkout master\n> > echo Hi > file3; git add file3; git commit -m file3\n> > git checkout branch\n> > git merge master\n> > \n> > # Then I'd normally do the following which causes a fast forward\n> > #git checkout master\n> > #git merge branch\n> > \n> > # Now I tried this, which also results in a fast-forward:\n> > git checkout -b merge\n> > git reset --hard master\n> > git merge branch\n> \n> I believe you misunderstood my suggestion.  In using a \"build\" branch,\n> you would not merge master into branch, as you did above.  Instead, you\n> would create a third, unpublished branch to hold the merge.\n\nAlmost though so.\n\n> At the same time, I have a slightly better understanding of what it is\n> you're trying to do.  If you are trying to keep up an SVN-like workflow\n> (namely pulling changes from trunk into a branch from time to time),\n> then my solution probably isn't suitable for you.  However, you might\n> consider why you actually /need/ to do that, outside of SVN convention.\n\nDue to the same reason for which the branch needs to be public at all,\nthere are other people who want to follow it and test it, while there\nare external dependencies that currently change quite often. So I need\nto get the relevant changes from trunk into my branch anyway, even with\nsvn conventions put aside (well, unless I force everyone else to merge\nover and over again). And as sometimes others commit to that branch, too\n(you just have to love that), keeping a separate branch for the final\nmerge isn't so nice either, as I'd need to constantly cherry-pick those\nchanges then and probably get even more conflicts along the way.\n\nThat said, Google finally liked some of the search terms that I threw at\nit and revealed a thread [1] from march, where Linus was torn on whether\nor not a --no-fast-forward option should be introduced. That sounds like\nit would help here, any chance of getting such a thing?\n\nThanks,\nBjörn\n\n[1]\nhttp://lists-archives.org/git/419374-git-merge-and-merge-message.html\n"},{"id":"54697","messageId":"47037F95.2040605@op5.se","threadId":"10087","inReplyTo":"20071003010233.GA8610@atjola.homenet","subject":"Re: git-svn merge helper","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-03T11:40:05Z","receivedAt":"2007-10-03T11:40:05Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Björn Steinbrink wrote:\n> On 2007.10.02 20:42:52 -0400, Steven Walter wrote:\n>> On Wed, Oct 03, 2007 at 12:38:13AM +0200, Björn Steinbrink wrote:\n>>>> The other option is to have a \"build\" branch.  By example:\n>>>>\n>>>> git checkout build\n>>>> git reset --hard master\n>>>> git merge mybranch\n>>>> make\n>>>>\n>>>> In that way, I have branch with the latest changes from head and the\n>>>> changes from mybranch together.  The downside to this method is that you\n>>>> may have to repeated resolve merges.  Despite the downsides, I find\n>>>> these two methods to work quite well.\n>>> Thanks, but it makes no difference here, it stil results in a fast\n>>> forward. This is a small test case which exhibits the behaviour and\n>>> matches my current workflow with git-svn (except for the dcommits):\n>>>\n>>> git init\n>>> echo Hi > file1; git add file1; git commit -m file1\n>>> git checkout -b branch\n>>> echo Hi > file2; git add file2; git commit -m file2\n>>> git checkout master\n>>> echo Hi > file3; git add file3; git commit -m file3\n>>> git checkout branch\n>>> git merge master\n>>>\n>>> # Then I'd normally do the following which causes a fast forward\n>>> #git checkout master\n>>> #git merge branch\n>>>\n>>> # Now I tried this, which also results in a fast-forward:\n>>> git checkout -b merge\n>>> git reset --hard master\n>>> git merge branch\n>> I believe you misunderstood my suggestion.  In using a \"build\" branch,\n>> you would not merge master into branch, as you did above.  Instead, you\n>> would create a third, unpublished branch to hold the merge.\n> \n> Almost though so.\n> \n>> At the same time, I have a slightly better understanding of what it is\n>> you're trying to do.  If you are trying to keep up an SVN-like workflow\n>> (namely pulling changes from trunk into a branch from time to time),\n>> then my solution probably isn't suitable for you.  However, you might\n>> consider why you actually /need/ to do that, outside of SVN convention.\n> \n> Due to the same reason for which the branch needs to be public at all,\n> there are other people who want to follow it and test it, while there\n> are external dependencies that currently change quite often. So I need\n> to get the relevant changes from trunk into my branch anyway, even with\n> svn conventions put aside (well, unless I force everyone else to merge\n> over and over again). And as sometimes others commit to that branch, too\n> (you just have to love that), keeping a separate branch for the final\n> merge isn't so nice either, as I'd need to constantly cherry-pick those\n> changes then and probably get even more conflicts along the way.\n> \n> That said, Google finally liked some of the search terms that I threw at\n> it and revealed a thread [1] from march, where Linus was torn on whether\n> or not a --no-fast-forward option should be introduced. That sounds like\n> it would help here, any chance of getting such a thing?\n> \n\nIs this what you're looking for? It's in the 'next' branch in git.git.\n\ncommit d66424c4ac661c69640765260235452499d80378\nAuthor: Lars Hjemli <hjemli@gmail.com>\nDate:   Mon Sep 24 00:51:45 2007 +0200\n\n    git-merge: add --ff and --no-ff options\n    \n    These new options can be used to control the policy for fast-forward\n    merges: --ff allows it (this is the default) while --no-ff will create\n    a merge commit.\n    \n    Signed-off-by: Lars Hjemli <hjemli@gmail.com>\n    Signed-off-by: Junio C Hamano <gitster@pobox.com>\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"}]}