Eric Wong <normalperson@xxxxxxxx> writes: > David Kastrup <dak@xxxxxxx> wrote: >> 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. > > 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. >> 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. > > Interesting, I've never considered it a problem (probably because > I know and trust the code I wrote :). Good idea though. > > Junio: could you please apply the following trivial patch? Thanks. > > From a8ae91019a2ededd0e3d455fdd78655c086ea3b3 Mon Sep 17 00:00:00 2001 > From: Eric Wong <normalperson@xxxxxxxx> > Date: Wed, 22 Aug 2007 22:14:31 -0700 > Subject: [PATCH] git-svn: dcommit prints out the URL to be committed to > > This will print out the URL that dcommit will operate on. > If used with --dry-run this will print out the URL without > making changes to the repository. > > Signed-off-by: Eric Wong <normalperson@xxxxxxxx> Acked-by: David Kastrup<dak@xxxxxxx> 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. -- 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
