I've read a great deal of "go from svn to git" and other "git-svn workflow" articles on the web, and still I think they often deal with overly simple situations. They are often targeted at guys who just want to use git and hack locally, without using the full power of git, like pull, fetch, merge and the like between multiple developers who would all have cloned the svn repository with git-svn, then still expect to be able to push their changes any time to the (official) svn repository, and get back to working in git and sharing their stuff etc.
Whenever these articles admit you can't do everything you'd do in pure git, the consequences and possible screw ups are never clearly explained (or maybe it's just me ?). Even the git-svn man page mentions caveats, but not really in an extensive manner.
Based on what I've read, I feel there could be problems when git-svn is used in that specific way, which I'll describe below. Can someone tell me if I'm right about this ?
Here is the "wanted" way of doing things:
- We have a project in a svn repository
- Developer A git-svn-clone's the svn repo. He begins to hack things locally
- Developer B git-svn-clone's the same svn repo. He begins to hack things on his own.
- After doing that for some time, possibly adding devs C/D/..., and having other developers who do "standard" svn commits to the original repo, the git users would want to share their code and do all kinds of git magic.
- Any one of those git users would like to be able to push the now merged changes to svn (dcommit?)
My question is: am I dreaming? I read some time ago, in a git book I think, that git-svn-clone could create git repositories that are of course a "mirror" of the svn repo, but that git repos created that way by different developers would have different "ids" and commits would have different hashes. So my understanding was that those git repos wouldn't share any common git