Hi Pico, I will try answer your question, but unfortunately I don't have much time for detail explanations, so maybe someone else will add a few more comments. On Wed, Sep 17, 2008 at 04:09:51PM +0200, Pico Geyer wrote: > > I'm going to give example commands to confirm my understanding of the > git-svn workflow you described. > Any comments or corrections are welcome. > > On the local server, get a clone of the repository: > srvA# git svn clone http://server.com/repo/proj/trunk proj > srvA# cd proj > > Create a local branch, where developers will push to > srvA# git branch integration > > Now a developer clones the repository on the server, and makes a local > branch for developement: > dev1# git clone ssh://svrA/path/to/repo > dev1# git checkout -b new_featureX > (Developer makes some changes and commits to the new_featureX branch) I believe developers should start from the integration branch, i.e.: git checkout -b new_featureX origin/integration > > Developer now pushes the changes to the integration branch > dev1# git push origin new_featureX:integration If someone already push there, push will refuse saying that it is non-fast forward update. So, the developer will have to rebase his/her branch on top of origin/integration: git fetch && git rebase origin/integration or provided that you created your branch from origin/integration, you can run: git pull --rebase which does git fetch and rebase on the top of the original branch. > > The merge master now rebases the changes on to the master branch: > srvA# git rebase integration What this commands does is to rebase your current branch on top of the integration branch. I suppose you have something like this before running it: master integration o------o-----o-------o If you are staying at the master, it will advance master to integration. So, yes, it does what you need, but your wording: "rebases the changes on to the master branch" is not correct, because it is master is rebased on top of integration, which in your case is just fast-forward update of it to integration: integration=master o------o-----o-------o you can have the same effect by "git merge integration". > > Now push the changes to the upstream subversion server: > srvA# git svn dcommit I usually run "git svn dcommit --dry-run" first to make sure that it will commit what I want. It is very useful when you try a new setup. > > At some stage svn users will commit to the subversion repository, and > we will need to pull changes into srvA: > srvA# git svn rebase Yes, but you usually do that before git svn dcommit... > > Now the integration branch does not include the changes in master, so > rebase the changes to integration: > srvA# git rebase master integration That is okay but may lead to the situation that conflicts that were already resolved during git svn rebase will be re-emerge again. You can force integration branch to be the same master after you have dcommited changes to SVN using the following command: git branch -f integration master but if someone push into repository after the point where 'master' was equal to 'integration' then those changes may be lost. To prevent this from happening, you can lock repository (or only this particular branch) from being push into when you dcommit changes to svn. Then when you have finished, you can safely use the above command. The lock can be implemented using the 'update' hook (for instance, the hook verifies whether the "integration.lock" tag exists, if it does then the hook exists with non-zero value). > > Finally the developer needs those changes too, so on his master branch: > dev1# git rebase origin No, it is git fetch && git rebase origin/integration or just git pull --rebase provided that you started your branch from origin/integration. > > Is this the process that you were trying to describe? > Any additional steps that need to be added? Yes, basically, it is. It could be some variations though. Instead of having the integration branch in the repository that you use to sync with SVN, you can have a separate bare repository where 'master' will represent the integration branch, while git-svn repository is private to the merge master. The advantage is that merge master does not need the shell access to the server. Also, developers see only one branch 'master' (less confusion about what to use as the starting point). In this setup, you need to allow to the merge master non-fast forward update to the bare repository (to update 'master' after commiting changes to SVN), while the rest developers should have only fast-forward update. > > And how do I make sure that when developers push to the server that it > results in a fast-forward merge? Do I do that with commit hooks? No, all commits and merges are purely local things. git push never merges anything, it only propogates changes and update the branch references. The only thing you should guarantee that no one (except the merge master if necessary) can do non-fast forward push to server. To disable to all users non-fast forward update, you can set receive.denyNonFastForwards = true If you disable to some users but not to others then you can use either $GIT_DIR/hooks/pre-receive or $GIT_DIR/hooks/update. See man git-receive-pack for more information, and examples of the update hook included in Git. Dmitry -- 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
