{"thread":{"id":"15536","subject":"Help using Git(-svn) for specific use case","startedAt":"2008-09-15T12:50:00Z","lastAt":"2008-09-18T05:56:28Z","messageCount":9,"participants":["Pico Geyer","Michael J Gruber","Dmitry Potapov","Sverre Rabbelier"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"90737","messageId":"aa2b76740809150550q724ab0f4x99a27fa21d90c0fb@mail.gmail.com","threadId":"15536","inReplyTo":null,"subject":"Help using Git(-svn) for specific use case","fromName":"Pico Geyer","fromEmail":"picogeyer@gmail.com","sentAt":"2008-09-15T12:50:00Z","receivedAt":"2008-09-15T12:50:00Z","isPatch":false,"sender":{"key":"picogeyer@gmail.com","avatar":null},"body":"Hi all.\n\nI'd like to start using Git within our company. I'm still trying to\ndetermine if Git can work in our scenario.\nMay be someone can offer some advice.\nOur scenario is as follows:\nWe have a handful of developers which work at a branch office. This\noffice has a rather slow internet connection.\nAt the head office, we are (still) using a Subversion server to host\nour source code.\nAt the branch office, we would like to do the following:\n* Fetch the latest code from the subversion server.\n* Push changes that we have made at the remote office back to upstream\nSVN server.\n* Be able to share source code changes locally (at the branch office)\nbetween developers.\n\nThe solution that I imagined is that we would setup a server (lets\ncall it A) at the branch office with a Git repository, that all the\ndevelopers can access.\nDevelopers would then clone the server repository A, make mods and\nthen push changes back to A.\nIt would be nice if git users could commit to a subversion branch.\nA merge master would then (as necessary) use svn dcommit to push the\nchanges up to the svn server.\nIs this scenario possible?\n\n>From the git-svn man page: \"git-clone does not clone branches under\nthe refs/remotes/ hierarchy or any git-svn metadata, or config. So\nrepositories created and managed with using git-svn should use rsync\nfor cloning, if cloning is to be done at all.\"\nDoes that mean that one should not push changes to a repository that\nwas created with \"git svn clone ...\"?\n\nThanks in advance for any advice.\n\nPico Geyer\n"},{"id":"90744","messageId":"48CE7B71.4090702@fastmail.fm","threadId":"15536","inReplyTo":"aa2b76740809150550q724ab0f4x99a27fa21d90c0fb@mail.gmail.com","subject":"Re: Help using Git(-svn) for specific use case","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-09-15T15:12:49Z","receivedAt":"2008-09-15T15:12:49Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Pico Geyer venit, vidit, dixit 15.09.2008 14:50:\n> Hi all.\n> \n> I'd like to start using Git within our company. I'm still trying to\n> determine if Git can work in our scenario.\n> May be someone can offer some advice.\n> Our scenario is as follows:\n> We have a handful of developers which work at a branch office. This\n> office has a rather slow internet connection.\n> At the head office, we are (still) using a Subversion server to host\n> our source code.\n> At the branch office, we would like to do the following:\n> * Fetch the latest code from the subversion server.\n> * Push changes that we have made at the remote office back to upstream\n> SVN server.\n> * Be able to share source code changes locally (at the branch office)\n> between developers.\n> \n> The solution that I imagined is that we would setup a server (lets\n> call it A) at the branch office with a Git repository, that all the\n> developers can access.\n> Developers would then clone the server repository A, make mods and\n> then push changes back to A.\n> It would be nice if git users could commit to a subversion branch.\n> A merge master would then (as necessary) use svn dcommit to push the\n> changes up to the svn server.\n> Is this scenario possible?\n> \n> From the git-svn man page: \"git-clone does not clone branches under\n> the refs/remotes/ hierarchy or any git-svn metadata, or config. So\n> repositories created and managed with using git-svn should use rsync\n> for cloning, if cloning is to be done at all.\"\n\nThat is true if you mean by \"clone\" a complete copy.\n\n> Does that mean that one should not push changes to a repository that\n> was created with \"git svn clone ...\"?\n\nWhat matters is which branches you push into.\n\nYour developers don't need to push/commit to svn, only into A, if I\nunderstood correctly. Do they need svn-metadata (besides svn revision\nnumbers)?\nIf not then the interaction between A and the developers can be a normal\ngit workflow between git managed branches, and \"git clone\" will do fine.\n\nMerge master at A could do the following:\n- use git svn to keep the svn (remote) branches at A in sync with the\ncentral subversion server\n- push them to proper git branches in A, which get picked up by\ndevelopers' \" git clone\"\n- maintain integration branches for integrating the changes coming fro\nthe developers\n- dcommit the svn tracking branches back to the central svn server\n\nDisadvantage:\nIf changes are dcommitted to svn, synced back with git svn fetch, and\nthen fetched/pull by the developers their commit will look different\n(addition git svn info in the commit message). This is similar to a\nworkflow where you submit by e-mail and your integrated patches get a\ndifferent sha1.\n\nAdvantage:\nFor all developers, everything is just git. Only megre master needs to\nknow git svn.\n\nCheers,\nMichael\n"},{"id":"90765","messageId":"37fcd2780809151255q278b1786ub4caec9022d7b082@mail.gmail.com","threadId":"15536","inReplyTo":"aa2b76740809150550q724ab0f4x99a27fa21d90c0fb@mail.gmail.com","subject":"Re: Help using Git(-svn) for specific use case","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-09-15T19:55:13Z","receivedAt":"2008-09-15T19:55:13Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Sep 15, 2008 at 4:50 PM, Pico Geyer <picogeyer@gmail.com> wrote:\n>\n> At the head office, we are (still) using a Subversion server to host\n> our source code.\n> At the branch office, we would like to do the following:\n> * Fetch the latest code from the subversion server.\n> * Push changes that we have made at the remote office back to upstream\n> SVN server.\n> * Be able to share source code changes locally (at the branch office)\n> between developers.\n\nI used Git in somewhat similar situation where almost all development\nwas done in Git mirror of SVN, and then the work was propagated to SVN.\nThere are some limitations with this approach. The most important is\nthat SVN does not support merges, so you have to linerialize all history\nthat you want to commit in SVN. That means that you are going to use git\nrebase a lot to rewrite history, which is a PITA. Another problem with\nthis approach is that the author is not preserved. In SVN, all commits will\nlook like all changes are done by the person who run \"git svn dcommit\".\n\nYet, despite of all these limitations caused by using SVN as backend,\nit was far more pleasant to work with Git than with SVN (you can save\nyour work in progress, you can easily organize the review process,\nand many other features such as \"git bisect\" or \"git log -S\" just to\nname a few...).\n\n>\n> The solution that I imagined is that we would setup a server (lets\n> call it A) at the branch office with a Git repository, that all the\n> developers can access.\n> Developers would then clone the server repository A, make mods and\n> then push changes back to A.\n> It would be nice if git users could commit to a subversion branch.\n> A merge master would then (as necessary) use svn dcommit to push the\n> changes up to the svn server.\n> Is this scenario possible?\n\nEach user has its own copy of the whole repository and they always\ncommit to their _local_ branches. Then they can push their changes to\nthe Git repo on your server, but it is a bad idea to push changes to\na local branch of a non-bare repository especially if that branch is\nchecked out, because push does not (and should not!) update the working\ntree and that leads to the situation where all pushed changes are\nlooked undo in the working tree of that repository. Therefore, you\nwill probably have a separately integration branch to which users\nwill push. Oftentimes, users will have to rebase their work on top the\nintegration branch to be able to push on it (only fast-forward push\nshould be allowed).\n\nThe merge master will merge this branch to the local branch assotiated\nwith subversion (it will be fast-forward, not a real merge) and then\nrun git svn dcommit to propagate to subversion.\n\nIf there were some conflicting changes in subversion repo, the merge\nmaster will have to resolve them. After that update the merge base\nshould be updated (using git branch -f) to point out to the top of\nthe subversion branch.\n\nIf users have some changes that were based on the old integration\nbranches they will have to rebase them to the new position of the\nintegration branch. As I said above, git rebase is going to be very\noften operation in this workflow.\n\nNOTE: branches in git differs from what they are in subversion. In\nessence, they are no more than pointers to where to add the next\ncommit. When I learned Git, I found very useful the article called\n\"Git for computer scientists\" to understand basic ideas of how Git\nworks: http://eagain.net/articles/git-for-computer-scientists/\n\n>\n> From the git-svn man page: \"git-clone does not clone branches under\n> the refs/remotes/ hierarchy or any git-svn metadata, or config. So\n> repositories created and managed with using git-svn should use rsync\n> for cloning, if cloning is to be done at all.\"\n> Does that mean that one should not push changes to a repository that\n> was created with \"git svn clone ...\"?\n\nNo, what the above description says is that SVN specific information is\nnot cloned when you clone a repo created by svn. It means that users who\ncloned from you will not be able to use git-svn to push their changes in\nthe original subversion repository. Yet, they can push to your repository\nas to any other Git repository.\n\nDmitry\n"},{"id":"90773","messageId":"bd6139dc0809151359i357987c5vb2544b1b5c99802f@mail.gmail.com","threadId":"15536","inReplyTo":"37fcd2780809151255q278b1786ub4caec9022d7b082@mail.gmail.com","subject":"Re: Help using Git(-svn) for specific use case","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-09-15T20:59:10Z","receivedAt":"2008-09-15T20:59:10Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, Sep 15, 2008 at 21:55, Dmitry Potapov <dpotapov@gmail.com> wrote:\n> [...] Another problem with\n> this approach is that the author is not preserved. In SVN, all commits will\n> look like all changes are done by the person who run \"git svn dcommit\".\n\nI thought this was fixed in a more recent version of git-svn? Didn't\nit even work both ways?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"90776","messageId":"48CED08F.5040602@drmicha.warpmail.net","threadId":"15536","inReplyTo":"bd6139dc0809151359i357987c5vb2544b1b5c99802f@mail.gmail.com","subject":"Re: Help using Git(-svn) for specific use case","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-09-15T21:15:59Z","receivedAt":"2008-09-15T21:15:59Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Sverre Rabbelier venit, vidit, dixit 15.09.2008 22:59:\n> On Mon, Sep 15, 2008 at 21:55, Dmitry Potapov <dpotapov@gmail.com> wrote:\n>> [...] Another problem with\n>> this approach is that the author is not preserved. In SVN, all commits will\n>> look like all changes are done by the person who run \"git svn dcommit\".\n> \n> I thought this was fixed in a more recent version of git-svn? Didn't\n> it even work both ways?\n\nKind of. You can't fake a different author when committing to svn. But\n\"--add-author-from\" makes dcommit embed the author in the svn commit\nmessage (if there's no from nor sob), and \"--use-log-author\" makes fetch\nlook for that info and use it.\n\nMichael\n"},{"id":"90777","messageId":"20080915214740.GI28210@dpotapov.dyndns.org","threadId":"15536","inReplyTo":"48CED08F.5040602@drmicha.warpmail.net","subject":"Re: Help using Git(-svn) for specific use case","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-09-15T21:47:40Z","receivedAt":"2008-09-15T21:47:40Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Sep 15, 2008 at 11:15:59PM +0200, Michael J Gruber wrote:\n> Sverre Rabbelier venit, vidit, dixit 15.09.2008 22:59:\n> > \n> > I thought this was fixed in a more recent version of git-svn? Didn't\n> > it even work both ways?\n> \n> Kind of. You can't fake a different author when committing to svn.\n\nThis is not exactly correct as you can fake author if you have the right\nto change the svn:author property (or what is its name?), but by default\nthis is not allowed to anyone, and git-svn does not support this method\nanyway.\n\n> But\n> \"--add-author-from\" makes dcommit embed the author in the svn commit\n> message (if there's no from nor sob), and \"--use-log-author\" makes fetch\n> look for that info and use it.\n\nYes, it works. And it is very useful especially you are going eventually\nconvert your SVN repository in Git (so all authorship information will\nbe retain). Probably, I should have mentioned this possibility.\n\nThanks,\nDmitry\n"},{"id":"90786","messageId":"aa2b76740809151553v70206abhe02d0859fdc62378@mail.gmail.com","threadId":"15536","inReplyTo":"20080915214740.GI28210@dpotapov.dyndns.org","subject":"Re: Help using Git(-svn) for specific use case","fromName":"Pico Geyer","fromEmail":"picogeyer@gmail.com","sentAt":"2008-09-15T22:53:05Z","receivedAt":"2008-09-15T22:53:05Z","isPatch":false,"sender":{"key":"picogeyer@gmail.com","avatar":null},"body":"Thanks guys for your replies and advice.\n\nI'm going to be trying to configure such a setup tomorrow.\nI'll probably have more questions :-)\n\nRegards,\nPico Geyer\n\nOn Mon, Sep 15, 2008 at 11:47 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:\n> On Mon, Sep 15, 2008 at 11:15:59PM +0200, Michael J Gruber wrote:\n>> Sverre Rabbelier venit, vidit, dixit 15.09.2008 22:59:\n>> >\n>> > I thought this was fixed in a more recent version of git-svn? Didn't\n>> > it even work both ways?\n>>\n>> Kind of. You can't fake a different author when committing to svn.\n>\n> This is not exactly correct as you can fake author if you have the right\n> to change the svn:author property (or what is its name?), but by default\n> this is not allowed to anyone, and git-svn does not support this method\n> anyway.\n>\n>> But\n>> \"--add-author-from\" makes dcommit embed the author in the svn commit\n>> message (if there's no from nor sob), and \"--use-log-author\" makes fetch\n>> look for that info and use it.\n>\n> Yes, it works. And it is very useful especially you are going eventually\n> convert your SVN repository in Git (so all authorship information will\n> be retain). Probably, I should have mentioned this possibility.\n>\n> Thanks,\n> Dmitry\n>\n"},{"id":"90945","messageId":"aa2b76740809170709y77275473k93d48e354bea55e5@mail.gmail.com","threadId":"15536","inReplyTo":"37fcd2780809151255q278b1786ub4caec9022d7b082@mail.gmail.com","subject":"Re: Help using Git(-svn) for specific use case","fromName":"Pico Geyer","fromEmail":"picogeyer@gmail.com","sentAt":"2008-09-17T14:09:51Z","receivedAt":"2008-09-17T14:09:51Z","isPatch":false,"sender":{"key":"picogeyer@gmail.com","avatar":null},"body":"Hi Dmitry\n\nI'm going to give example commands to confirm my understanding of the\ngit-svn workflow you described.\nAny comments or corrections are welcome.\n\nOn the local server, get a clone of the repository:\nsrvA# git svn clone http://server.com/repo/proj/trunk proj\nsrvA# cd proj\n\nCreate a local branch, where developers will push to\nsrvA# git branch integration\n\nNow a developer clones the repository on the server, and makes a local\nbranch for developement:\ndev1# git clone ssh://svrA/path/to/repo\ndev1# git checkout -b new_featureX\n(Developer makes some changes and commits to the new_featureX branch)\n\nDeveloper now pushes the changes to the integration branch\ndev1# git push origin new_featureX:integration\n\nThe merge master now rebases the changes on to the master branch:\nsrvA# git rebase integration\n\nNow push the changes to the upstream subversion server:\nsrvA# git svn dcommit\n\nAt some stage svn users will commit to the subversion repository, and\nwe will need to pull changes into srvA:\nsrvA# git svn rebase\n\nNow the integration branch does not include the changes in master, so\nrebase the changes to integration:\nsrvA# git rebase master integration\n\nFinally the developer needs those changes too, so on his master branch:\ndev1# git rebase origin\n\nIs this the process that you were trying to describe?\nAny additional steps that need to be added?\n\nAnd how do I make sure that when developers push to the server that it\nresults in a fast-forward merge? Do I do that with commit hooks?\n\nThanks again for the advice.\nPico\n\nOn Mon, Sep 15, 2008 at 9:55 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:\n> On Mon, Sep 15, 2008 at 4:50 PM, Pico Geyer <picogeyer@gmail.com> wrote:\n>>\n>> At the head office, we are (still) using a Subversion server to host\n>> our source code.\n>> At the branch office, we would like to do the following:\n>> * Fetch the latest code from the subversion server.\n>> * Push changes that we have made at the remote office back to upstream\n>> SVN server.\n>> * Be able to share source code changes locally (at the branch office)\n>> between developers.\n>\n> I used Git in somewhat similar situation where almost all development\n> was done in Git mirror of SVN, and then the work was propagated to SVN.\n> There are some limitations with this approach. The most important is\n> that SVN does not support merges, so you have to linerialize all history\n> that you want to commit in SVN. That means that you are going to use git\n> rebase a lot to rewrite history, which is a PITA. Another problem with\n> this approach is that the author is not preserved. In SVN, all commits will\n> look like all changes are done by the person who run \"git svn dcommit\".\n>\n> Yet, despite of all these limitations caused by using SVN as backend,\n> it was far more pleasant to work with Git than with SVN (you can save\n> your work in progress, you can easily organize the review process,\n> and many other features such as \"git bisect\" or \"git log -S\" just to\n> name a few...).\n>\n>>\n>> The solution that I imagined is that we would setup a server (lets\n>> call it A) at the branch office with a Git repository, that all the\n>> developers can access.\n>> Developers would then clone the server repository A, make mods and\n>> then push changes back to A.\n>> It would be nice if git users could commit to a subversion branch.\n>> A merge master would then (as necessary) use svn dcommit to push the\n>> changes up to the svn server.\n>> Is this scenario possible?\n>\n> Each user has its own copy of the whole repository and they always\n> commit to their _local_ branches. Then they can push their changes to\n> the Git repo on your server, but it is a bad idea to push changes to\n> a local branch of a non-bare repository especially if that branch is\n> checked out, because push does not (and should not!) update the working\n> tree and that leads to the situation where all pushed changes are\n> looked undo in the working tree of that repository. Therefore, you\n> will probably have a separately integration branch to which users\n> will push. Oftentimes, users will have to rebase their work on top the\n> integration branch to be able to push on it (only fast-forward push\n> should be allowed).\n>\n> The merge master will merge this branch to the local branch assotiated\n> with subversion (it will be fast-forward, not a real merge) and then\n> run git svn dcommit to propagate to subversion.\n>\n> If there were some conflicting changes in subversion repo, the merge\n> master will have to resolve them. After that update the merge base\n> should be updated (using git branch -f) to point out to the top of\n> the subversion branch.\n>\n> If users have some changes that were based on the old integration\n> branches they will have to rebase them to the new position of the\n> integration branch. As I said above, git rebase is going to be very\n> often operation in this workflow.\n>\n> NOTE: branches in git differs from what they are in subversion. In\n> essence, they are no more than pointers to where to add the next\n> commit. When I learned Git, I found very useful the article called\n> \"Git for computer scientists\" to understand basic ideas of how Git\n> works: http://eagain.net/articles/git-for-computer-scientists/\n>\n>>\n>> From the git-svn man page: \"git-clone does not clone branches under\n>> the refs/remotes/ hierarchy or any git-svn metadata, or config. So\n>> repositories created and managed with using git-svn should use rsync\n>> for cloning, if cloning is to be done at all.\"\n>> Does that mean that one should not push changes to a repository that\n>> was created with \"git svn clone ...\"?\n>\n> No, what the above description says is that SVN specific information is\n> not cloned when you clone a repo created by svn. It means that users who\n> cloned from you will not be able to use git-svn to push their changes in\n> the original subversion repository. Yet, they can push to your repository\n> as to any other Git repository.\n>\n> Dmitry\n>\n"},{"id":"90990","messageId":"20080918055628.GB21650@dpotapov.dyndns.org","threadId":"15536","inReplyTo":"aa2b76740809170709y77275473k93d48e354bea55e5@mail.gmail.com","subject":"Re: Help using Git(-svn) for specific use case","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-09-18T05:56:28Z","receivedAt":"2008-09-18T05:56:28Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"Hi Pico,\n\nI will try answer your question, but unfortunately I don't have much\ntime for detail explanations, so maybe someone else will add a few\nmore comments.\n\nOn Wed, Sep 17, 2008 at 04:09:51PM +0200, Pico Geyer wrote:\n> \n> I'm going to give example commands to confirm my understanding of the\n> git-svn workflow you described.\n> Any comments or corrections are welcome.\n> \n> On the local server, get a clone of the repository:\n> srvA# git svn clone http://server.com/repo/proj/trunk proj\n> srvA# cd proj\n> \n> Create a local branch, where developers will push to\n> srvA# git branch integration\n> \n> Now a developer clones the repository on the server, and makes a local\n> branch for developement:\n> dev1# git clone ssh://svrA/path/to/repo\n> dev1# git checkout -b new_featureX\n> (Developer makes some changes and commits to the new_featureX branch)\n\nI believe developers should start from the integration branch, i.e.:\n\ngit checkout -b new_featureX origin/integration\n\n> \n> Developer now pushes the changes to the integration branch\n> dev1# git push origin new_featureX:integration\n\nIf someone already push there, push will refuse saying that it is\nnon-fast forward update. So, the developer will have to rebase his/her\nbranch on top of origin/integration:\n\n  git fetch && git rebase origin/integration\n\nor provided that you created your branch from origin/integration,\nyou can run:\n\n  git pull --rebase\n\nwhich does git fetch and rebase on the top of the original branch.\n\n> \n> The merge master now rebases the changes on to the master branch:\n> srvA# git rebase integration\n\nWhat this commands does is to rebase your current branch on top\nof the integration branch. I suppose you have something like\nthis before running it:\n\nmaster            integration\n o------o-----o-------o\n\nIf you are staying at the master, it will advance master to\nintegration. So, yes, it does what you need, but your wording:\n\"rebases the changes on to the master branch\" is not correct,\nbecause it is master is rebased on top of integration, which\nin your case is just fast-forward update of it to integration:\n\n                  integration=master\no------o-----o-------o\n\nyou can have the same effect by \"git merge integration\".\n\n> \n> Now push the changes to the upstream subversion server:\n> srvA# git svn dcommit\n\nI usually run \"git svn dcommit --dry-run\" first to make sure that it\nwill commit what I want. It is very useful when you try a new setup.\n\n> \n> At some stage svn users will commit to the subversion repository, and\n> we will need to pull changes into srvA:\n> srvA# git svn rebase\n\nYes, but you usually do that before git svn dcommit...\n\n> \n> Now the integration branch does not include the changes in master, so\n> rebase the changes to integration:\n> srvA# git rebase master integration\n\nThat is okay but may lead to the situation that conflicts that were\nalready resolved during git svn rebase will be re-emerge again.\n\nYou can force integration branch to be the same master after you \nhave dcommited changes to SVN using the following command:\n   git branch -f integration master\nbut if someone push into repository after the point where 'master' was\nequal to 'integration' then those changes may be lost. To prevent this\nfrom happening, you can lock repository (or only this particular branch)\nfrom being push into when you dcommit changes to svn. Then when you have\nfinished, you can safely use the above command. The lock can be\nimplemented using the 'update' hook (for instance, the hook verifies\nwhether the \"integration.lock\" tag exists, if it does then the hook\nexists with non-zero value).\n\n> \n> Finally the developer needs those changes too, so on his master branch:\n> dev1# git rebase origin\n\nNo, it is\n  git fetch && git rebase origin/integration\nor just\n  git pull --rebase\nprovided that you started your branch from origin/integration.\n\n> \n> Is this the process that you were trying to describe?\n> Any additional steps that need to be added?\n\nYes, basically, it is. It could be some variations though. Instead of\nhaving the integration branch in the repository that you use to sync\nwith SVN, you can have a separate bare repository where 'master' will\nrepresent the integration branch, while git-svn repository is private to\nthe merge master. The advantage is that merge master does not need the\nshell access to the server. Also, developers see only one branch 'master'\n(less confusion about what to use as the starting point). In this setup,\nyou need to allow to the merge master non-fast forward update to the\nbare repository (to update 'master' after commiting changes to SVN),\nwhile the rest developers should have only fast-forward update.\n\n> \n> And how do I make sure that when developers push to the server that it\n> results in a fast-forward merge? Do I do that with commit hooks?\n\nNo, all commits and merges are purely local things. git push never\nmerges anything, it only propogates changes and update the branch\nreferences. The only thing you should guarantee that no one (except\nthe merge master if necessary) can do non-fast forward push to server.\nTo disable to all users non-fast forward update, you can set\nreceive.denyNonFastForwards = true\n\nIf you disable to some users but not to others then you can use\neither $GIT_DIR/hooks/pre-receive or $GIT_DIR/hooks/update.\nSee man git-receive-pack for more information, and examples\nof the update hook included in Git.\n\n\nDmitry\n"}]}