Hi all, I'm wondering if you could give me input on the suggested workflow when using Git on the client, a Git server repo and Subversion.
I've been using Git for my work projects for a couple of weeks now and I really like the advantages it offers. We use SVN as our primary source control system at work, so I rely heavily on git svn rebase and git svn dcommit. I actually have two workplaces, one at the office and one at home. Sometimes while I work on some Git topic branch I want to take those changes home and finish my work there. To make this happen I created a repo at Github to store my work in progress that's not yet ripe for SVN. Every time I switch workplaces I do a git push (to Github). After arriving at the new location, I run git pull to get my WIP changes. Every now and then it happens that there are some SVN commits made by my colleagues that I already pushed to Github. But if I arrive at the new location and I do a git svn rebase those SVN commits are applied again. The make things a bit better to understand: 1. At work Starting at SVN commit A work... git commit Colleage commits to SVN in the meantime: SVN commit B git svn rebase git push (I leave) Colleague commits to SVN: SVN commit C 2. At home: git pull origin master git svn rebase (to apply the colleague's changes in SVN commit C) Not only do my colleague's latest changes get applied (SVN commit C), but also those changes from SVN commit B will be rebased, often resulting in merge conflicts. Is there a way to omit SVN commit B during the SVN rebase? As matter of fact it's already in my Git repo (and the according git-svn-id is in the log). Thank you for any hints, Alex -- Alexander Groß http://therightstuff.de/
smime.p7s
Description: S/MIME cryptographic signature
