Junio C Hamano <gitster@xxxxxxxxx> writes: > Eric Wong <normalperson@xxxxxxxx> writes: > >> I've been meaning to do this for a while, hopefully this cuts >> down on the redundant mailing list traffic about these subjects. >> ... >> +CAVEATS >> +------- >> + >> +For the sake of simplicity and interoperating with a less-capable system >> +(SVN), it is recommended that all git-svn users clone, fetch and dcommit >> +directly from the SVN server, and avoid all git-clone/pull/merge/push >> +operations between git repositories and branches. The recommended >> +method of exchanging code between git branches and users is >> +git-format-patch and git-am, or just dcommiting to the SVN repository. >> + >> +Running 'git-merge' or 'git-pull' is NOT recommended on a branch you >> +plan to dcommit from. Subversion does not represent merges in any >> +reasonable or useful fashion; so users using Subversion cannot see any >> +merges you've made. > > Ok, my ruling before 1.5.3 is to take this patch, and encourage > interested parties to help Eric adding reliable support for the > feature after that, if such is possible. Couldn't we at least get a _documentation_ of the current behavior when actually using git for branch work? Knowing what will fail how and when is not as good as things just working as one would expect, but it certainly beats obscure warnings. For example, I consider it rather unacceptable that nowhere is documented just _how_ git-svn chooses one Subversion branch to commit to. It also drastically misrepresents the consequences: the problem is _not_ that users using Subversion cannot see merges. That is something that one can readily accept. The problem is that git-svn will dcommit to a seemingly random branch. -- 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
