Re: [PATCH] git-svn: update documentation with CAVEATS section

> Eric Wong <normalperson@yhbt.net> writes:
> > David Kastrup <dak@gnu.org> wrote:
> >> Junio C Hamano <gitster@pobox.com> writes:
> >> > Eric Wong <normalperson@yhbt.net> 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.
> >
> > dcommit always chooses the last SVN branch it branched off from.
> 
> No, it doesn't.  That's the problem.  If I do
> git-merge master
> in a side branch, and do git-svn dcommit afterwards, the commit
> goes to the master branch.
> 
> Which is utterly unexpected.

> This is already a _large_ help for avoiding clobbering the central
> repository.  But I stress that it would be much better if git-svn
> dcommit/rebase stayed exclusively on the branch that is associated
> with it/fetching in the "svn" config section, like git does in general
> with remotes.  No random branch jumping after merges or (to be
> _really_ avoided) rebases and certainly after cherry-picking within
> git.