On Jul 28, 2011, at 2:00 PM, David A. Greene wrote:> Bob Wilson <bob.wilson at apple.com> writes: > > >> It's a little awkward to set up a new repo that pulls from the git >> mirrors and also lets you use git-svn dcommit to push back, but that's >> a minor nuisance AFAICT. > > No to people who use git regularly, it isn't. git-svn imposes all sorts > of restrictions on what kind of commits it wants to see and the git user > ends up having to work around them. Things that are trivial with git > (merges) become more complicated with git-svn. This in turn > fundamentally changes how git can be used by the developer.Sorry, but I have no idea what you're talking about. I use git exclusively for all my llvm development, and I make extensive use of branches and merging. I haven't had any problems related to git-svn.
Bob Wilson <bob.wilson at apple.com> writes:>>> It's a little awkward to set up a new repo that pulls from the git >>> mirrors and also lets you use git-svn dcommit to push back, but that's >>> a minor nuisance AFAICT. >> >> No to people who use git regularly, it isn't. git-svn imposes all sorts >> of restrictions on what kind of commits it wants to see and the git user >> ends up having to work around them. Things that are trivial with git >> (merges) become more complicated with git-svn. This in turn >> fundamentally changes how git can be used by the developer. > > Sorry, but I have no idea what you're talking about. I use git > exclusively for all my llvm development, and I make extensive use of > branches and merging. I haven't had any problems related to git-svn.Exactly, you have no idea what he is talking about :-) The problem with git-svn is that once a revision is sent from git to svn, it comes back with a different identity (revision-id) so for git it is a new reivision. That's a PITA (or rebase hell, to be more descriptive) if you have branches containing the original revisions plus some others on top of them and later you want to merge svn's mainline into them. Variations of that scenario are to be expected on a team that contributes chunks of changes upstream but keep other changes internally or in development phase. git-svn works well if you are working on mutually independent features, one feature per branch.
Óscar Fuentes <ofv at wanadoo.es> writes:> Bob Wilson <bob.wilson at apple.com> writes: > >> Sorry, but I have no idea what you're talking about. I use git >> exclusively for all my llvm development, and I make extensive use of >> branches and merging. I haven't had any problems related to git-svn. > > Exactly, you have no idea what he is talking about :-) > > The problem with git-svn is that once a revision is sent from git to > svn, it comes back with a different identity (revision-id) so for git it > is a new reivision. That's a PITA (or rebase hell, to be more > descriptive) if you have branches containing the original revisions plus > some others on top of them and later you want to merge svn's mainline > into them. Variations of that scenario are to be expected on a team that > contributes chunks of changes upstream but keep other changes internally > or in development phase.Ding! ding! ding! ding! ding! :) git-svn is better than svn but it is still short of git proper. -Dave