Re: [PATCH] git-svn: update documentation with CAVEATS section
- From
David Kastrup <dak@gnu.org>
- Date
- Aug 23, 2007, 06:00 UTC
- Message-ID
- <85r6luiydb.fsf@lola.goethe.zz>
- In-Reply-To
- <20070823053009.GC4978@muzzle>
Eric Wong <normalperson@yhbt.net> writes:
Show 37 quoted lines
> 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.
Show 20 quoted lines
>> 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@yhbt.net> > 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@yhbt.net>
Acked-by: David Kastrup<dak@gnu.org>
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