All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: David Kastrup <dak@gnu.org>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] git-svn: update documentation with CAVEATS section
Date: Wed, 22 Aug 2007 22:30:09 -0700	[thread overview]
Message-ID: <20070823053009.GC4978@muzzle> (raw)
In-Reply-To: <853aybkwsc.fsf@lola.goethe.zz>

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.

> 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>
---
 git-svn.perl |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index d162114..7a8ffd5 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -370,6 +370,7 @@ sub cmd_dcommit {
 	$head ||= 'HEAD';
 	my @refs;
 	my ($url, $rev, $uuid, $gs) = working_head_info($head, \@refs);
+	print "Committing to $url ...\n";
 	unless ($gs) {
 		die "Unable to determine upstream SVN information from ",
 		    "$head history\n";
-- 
Eric Wong

  reply	other threads:[~2007-08-23  5:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-16  8:56 [PATCH] git-svn: update documentation with CAVEATS section Eric Wong
2007-08-22 22:41 ` Junio C Hamano
2007-08-22 22:51   ` David Kastrup
2007-08-23  5:30     ` Eric Wong [this message]
2007-08-23  6:00       ` David Kastrup
2007-08-23  6:26         ` Eric Wong
2007-08-23  7:48           ` David Kastrup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070823053009.GC4978@muzzle \
    --to=normalperson@yhbt.net \
    --cc=dak@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.