Eric Wong <normalperson@xxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> Actually I do. A major, if not primary, selling point of >> git-svn has been that svn cannot do merges but if you import to >> git you can, and I've had an impression that Sam's git-svn intro >> alludes to this capability as well. > > Wow. My primary reasons for git-svn are completely different: speed > and offline usability; and merging was not so much a concern for me. > >> If I understand you correctly, your position is that the svn side >> has the authoritative history when using git-svn, and we should >> refuse to do anything on the git side that the resulting history in >> svn cannot represent. I know and respect that you have thought >> about the issues involved long enough before that declaration of >> defeat, but at the same time, I would really hope that we can come >> up with a workable compromise to allow merge tracking on the git >> side. > > Yes. From what I gather, developers only use git-svn because they > don't have enough swing within their group to replace SVN. Not at all. Subversion has _working_ subproject support (which is rather easy, since every directory is treated the same and you can merge at every level). It also has other tools like "Trac". And it provides a _stable_ history and point of reference and backup. While I appreciate being able to create and undo almost any mess in my personal git repository (and this happens not infrequently), I would not want to propose that to everybody. git-svn makes it possible for me to keep the mess that is git to myself, and only expose others to the _results_ of my work with it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - 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
