On Fri, Mar 19, 2010 at 2:39 PM, Sverre Rabbelier <srabbelier@xxxxxxxxx> wrote: > On Fri, Mar 19, 2010 at 19:32, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: >> - all those "extra commands" that git-svn supports are considered >> backwards compatibility, even if they're absolutely obsolete because >> of newer commands, and therefore will be very hard to justify getting >> rid of > > I don't think this is true. The proposal is to implement > git-remote-svn, which would allow _native_ interaction with svn > repositories, so without using 'git svn'. It would allow 'git clone > svn://example.com/myrepo' and subsequent "git pull"s from that svn > source. Do you agree that makes (part of) your comments moot, or am I > missing something? I don't know enough about the proposal to comment on this part of the design. I do know that where git-svn fits into git's UI has not been the problem for me or my co-workers; we can learn some weirdo syntax if needed. Things like branching and merging, and git-svn redownloading the same stuff 100 times, and oddly-named-svn-branch-hierarchies, and git pulling between git-svn users, however, have given us lots of grief. For example, I'd be very happy to learn that your new design would allow two people to independently pull from svn://, do work in their respective copies of the git repositories, branch and merge all day long, pull from each other, and then push back to svn without a) making a mess of the svn repo and causing zillions of conflicts, or b) linearizing history and losing git's complex DAG. In the current version of git-svn this is very hard. 'git svn dcommit' generates entirely new git commit objects corresponding to the ones that were created in svn... but which nevertheless have your merge history included, which is awesome. But if a new person clones the svn repo from scratch, he will end up with git commits corresponding to those same ones from svn, but *without* the merge history, and therefore with different commit ids, and which therefore prevent push/pulling between other people who have cloned the repo. If the above explanation doesn't make any sense, let me know and I can clarify it further. If you know what I'm talking about and have either solved it or don't care about that use case, please just ignore me and I'll go back to hide in my hole :) Have fun, Avery -- 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