[PATCH 1/3] git-svn: color support for the log command

[PATCH 1/3] git-svn: color support for the log command

[Eric Wong]

 * match LESS environment settings to those in pager.c
 * parse diff.color and pager.color settings in the
   config file, and pass --color to git-log
 * --color and --pager= settings are supported

Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
 git-svn.perl |   67 ++++++++++++++++++++++++++++++++++++++++-----------------
 1 files changed, 47 insertions(+), 20 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index c3ad5ec..d8d8716 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -60,6 +60,7 @@ nag_lib() unless $_use_lib;
 my $_optimize_commits = 1 unless $ENV{GIT_SVN_NO_OPTIMIZE_COMMITS};
 my $sha1 = qr/[a-f\d]{40}/;
 my $sha1_short = qr/[a-f\d]{4,40}/;
+my $_esc_color = qr/(?:\033\[(?:(?:\d+;)*\d*)?m)*/;
 my ($_revision,$_stdin,$_no_ignore_ext,$_no_stop_copy,$_help,$_rmdir,$_edit,
 	$_find_copies_harder, $_l, $_cp_similarity, $_cp_remote,
 	$_repack, $_repack_nr, $_repack_flags, $_q,
@@ -68,7 +69,8 @@ my ($_revision,$_stdin,$_no_ignore_ext,$
 	$_limit, $_verbose, $_incremental, $_oneline, $_l_fmt, $_show_commit,
 	$_version, $_upgrade, $_authors, $_branch_all_refs, @_opt_m,
 	$_merge, $_strategy, $_dry_run, $_ignore_nodate, $_non_recursive,
-	$_username, $_config_dir, $_no_auth_cache, $_xfer_delta);
+	$_username, $_config_dir, $_no_auth_cache, $_xfer_delta,
+	$_pager, $_color);
 my (@_branch_from, %tree_map, %users, %rusers, %equiv);
 my ($_svn_co_url_revs, $_svn_pg_peg_revs);
 my @repo_path_split_cache;
@@ -135,6 +137,8 @@ my %cmd = (
 			  'show-commit' => \$_show_commit,
 			  'non-recursive' => \$_non_recursive,
 			  'authors-file|A=s' => \$_authors,
+			  'color' => \$_color,
+			  'pager=s' => \$_pager,
 			} ],
 	'commit-diff' => [ \&commit_diff, 'Commit a diff between two trees',
 			{ 'message|m=s' => \$_message,
@@ -759,16 +763,17 @@ sub show_log {
 		}
 	}
 
+	config_pager();
 	my $pid = open(my $log,'-|');
 	defined $pid or croak $!;
 	if (!$pid) {
 		exec(git_svn_log_cmd($r_min,$r_max), @args) or croak $!;
 	}
-	setup_pager();
+	run_pager();
 	my (@k, $c, $d);
 
 	while (<$log>) {
-		if (/^commit ($sha1_short)/o) {
+		if (/^${_esc_color}commit ($sha1_short)/o) {
 			my $cmt = $1;
 			if ($c && cmt_showable($c) && $c->{r} != $r_last) {
 				$r_last = $c->{r};
@@ -777,25 +782,25 @@ sub show_log {
 			}
 			$d = undef;
 			$c = { c => $cmt };
-		} elsif (/^author (.+) (\d+) ([\-\+]?\d+)$/) {
+		} elsif (/^${_esc_color}author (.+) (\d+) ([\-\+]?\d+)$/) {
 			get_author_info($c, $1, $2, $3);
-		} elsif (/^(?:tree|parent|committer) /) {
+		} elsif (/^${_esc_color}(?:tree|parent|committer) /) {
 			# ignore
-		} elsif (/^:\d{6} \d{6} $sha1_short/o) {
+		} elsif (/^${_esc_color}:\d{6} \d{6} $sha1_short/o) {
 			push @{$c->{raw}}, $_;
-		} elsif (/^[ACRMDT]\t/) {
+		} elsif (/^${_esc_color}[ACRMDT]\t/) {
 			# we could add $SVN->{svn_path} here, but that requires
 			# remote access at the moment (repo_path_split)...
-			s#^([ACRMDT])\t#   $1 #;
+			s#^(${_esc_color})([ACRMDT])\t#$1   $2 #;
 			push @{$c->{changed}}, $_;
-		} elsif (/^diff /) {
+		} elsif (/^${_esc_color}diff /) {
 			$d = 1;
 			push @{$c->{diff}}, $_;
 		} elsif ($d) {
 			push @{$c->{diff}}, $_;
-		} elsif (/^    (git-svn-id:.+)$/) {
+		} elsif (/^${_esc_color}    (git-svn-id:.+)$/) {
 			($c->{url}, $c->{r}, undef) = extract_metadata($1);
-		} elsif (s/^    //) {
+		} elsif (s/^${_esc_color}    //) {
 			push @{$c->{l}}, $_;
 		}
 	}
@@ -901,12 +906,30 @@ sub cmt_showable {
 	return defined $c->{r};
 }
 
+sub log_use_color {
+	return 1 if $_color;
+	my $dc;
+	chomp($dc = `git-repo-config --get diff.color`);
+	if ($dc eq 'auto') {
+		if (-t *STDOUT || (defined $_pager &&
+		    `git-repo-config --bool --get pager.color` !~ /^false/)) {
+			return ($ENV{TERM} && $ENV{TERM} ne 'dumb');
+		}
+		return 0;
+	}
+	return 0 if $dc eq 'never';
+	return 1 if $dc eq 'always';
+	chomp($dc = `git-repo-config --bool --get diff.color`);
+	$dc eq 'true';
+}
+
 sub git_svn_log_cmd {
 	my ($r_min, $r_max) = @_;
 	my @cmd = (qw/git-log --abbrev-commit --pretty=raw
 			--default/, "refs/remotes/$GIT_SVN");
 	push @cmd, '-r' unless $_non_recursive;
 	push @cmd, qw/--raw --name-status/ if $_verbose;
+	push @cmd, '--color' if log_use_color();
 	return @cmd unless defined $r_max;
 	if ($r_max == $r_min) {
 		push @cmd, '--max-count=1';
@@ -2533,14 +2556,18 @@ sub tz_to_s_offset {
 	return ($1 * 60) + ($tz * 3600);
 }
 
-sub setup_pager { # translated to Perl from pager.c
-	return unless (-t *STDOUT);
-	my $pager = $ENV{PAGER};
-	if (!defined $pager) {
-		$pager = 'less';
-	} elsif (length $pager == 0 || $pager eq 'cat') {
-		return;
+# adapted from pager.c
+sub config_pager {
+	$_pager ||= $ENV{GIT_PAGER} || $ENV{PAGER};
+	if (!defined $_pager) {
+		$_pager = 'less';
+	} elsif (length $_pager == 0 || $_pager eq 'cat') {
+		$_pager = undef;
 	}
+}
+
+sub run_pager {
+	return unless -t *STDOUT;
 	pipe my $rfd, my $wfd or return;
 	defined(my $pid = fork) or croak $!;
 	if (!$pid) {
@@ -2548,8 +2575,8 @@ sub setup_pager { # translated to Perl f
 		return;
 	}
 	open STDIN, '<&', $rfd or croak $!;
-	$ENV{LESS} ||= '-S';
-	exec $pager or croak "Can't run pager: $!\n";;
+	$ENV{LESS} ||= 'FRSX';
+	exec $_pager or croak "Can't run pager: $! ($_pager)\n";
 }
 
 sub get_author_info {
-- 
1.4.4.1.g22a08

[PATCH 2/3] git-svn: documentation updates

[Eric Wong]

Eliminate 'commit' from some places and plug 'dcommit' more.
Also update the section --id (GIT_SVN_ID) usage since we
have multi-init/multi-fetch now.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
 Documentation/git-svn.txt |   40 +++++++++++++++++++---------------------
 1 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index a764d1f..a45067e 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -49,7 +49,7 @@ latest revision.
 
 Note: You should never attempt to modify the remotes/git-svn
 branch outside of git-svn.  Instead, create a branch from
-remotes/git-svn and work on that branch.  Use the 'commit'
+remotes/git-svn and work on that branch.  Use the 'dcommit'
 command (see below) to write git commits back to
 remotes/git-svn.
 
@@ -274,7 +274,7 @@ ADVANCED OPTIONS
 
 -b<refname>::
 --branch <refname>::
-Used with 'fetch' or 'commit'.
+Used with 'fetch', 'dcommit' or 'commit'.
 
 This can be used to join arbitrary git branches to remotes/git-svn
 on new commits where the tree object is equivalent.
@@ -368,7 +368,7 @@ SVN was very wrong.
 Basic Examples
 ~~~~~~~~~~~~~~
 
-Tracking and contributing to an Subversion managed-project:
+Tracking and contributing to a Subversion-managed project:
 
 ------------------------------------------------------------------------
 # Initialize a repo (like git init-db):
@@ -377,10 +377,9 @@ Tracking and contributing to an Subversi
 	git-svn fetch
 # Create your own branch to hack on:
 	git checkout -b my-branch remotes/git-svn
-# Commit only the git commits you want to SVN:
-	git-svn commit <tree-ish> [<tree-ish_2> ...]
-# Commit all the git commits from my-branch that don't exist in SVN:
-	git-svn commit remotes/git-svn..my-branch
+# Do some work, and then commit your new changes to SVN, as well as
+# automatically updating your working HEAD:
+	git-svn dcommit
 # Something is committed to SVN, rebase the latest into your branch:
 	git-svn fetch && git rebase remotes/git-svn
 # Append svn:ignore settings to the default git exclude file:
@@ -404,26 +403,24 @@ which can lead to merge commits reversin
 DESIGN PHILOSOPHY
 -----------------
 Merge tracking in Subversion is lacking and doing branched development
-with Subversion is cumbersome as a result.  git-svn completely forgoes
-any automated merge/branch tracking on the Subversion side and leaves it
-entirely up to the user on the git side.  It's simply not worth it to do
-a useful translation when the original signal is weak.
+with Subversion is cumbersome as a result.  git-svn does not do
+automated merge/branch tracking by default and leaves it entirely up to
+the user on the git side.
 
 [[tracking-multiple-repos]]
 TRACKING MULTIPLE REPOSITORIES OR BRANCHES
 ------------------------------------------
-This is for advanced users, most users should ignore this section.
-
 Because git-svn does not care about relationships between different
 branches or directories in a Subversion repository, git-svn has a simple
 hack to allow it to track an arbitrary number of related _or_ unrelated
-SVN repositories via one git repository.  Simply set the GIT_SVN_ID
-environment variable to a name other other than "git-svn" (the default)
-and git-svn will ignore the contents of the $GIT_DIR/svn/git-svn directory
-and instead do all of its work in $GIT_DIR/svn/$GIT_SVN_ID for that
-invocation.  The interface branch will be remotes/$GIT_SVN_ID, instead of
-remotes/git-svn.  Any remotes/$GIT_SVN_ID branch should never be modified
-by the user outside of git-svn commands.
+SVN repositories via one git repository.  Simply use the --id/-i flag or
+set the GIT_SVN_ID environment variable to a name other other than
+"git-svn" (the default) and git-svn will ignore the contents of the
+$GIT_DIR/svn/git-svn directory and instead do all of its work in
+$GIT_DIR/svn/$GIT_SVN_ID for that invocation.  The interface branch will
+be remotes/$GIT_SVN_ID, instead of remotes/git-svn.  Any
+remotes/$GIT_SVN_ID branch should never be modified by the user outside
+of git-svn commands.
 
 [[fetch-args]]
 ADDITIONAL FETCH ARGUMENTS
@@ -486,7 +483,8 @@ If you are not using the SVN::* Perl lib
 conflicting changeset to SVN at a bad moment (right before you commit)
 causing a conflict and your commit to fail, your svn working tree
 ($GIT_DIR/git-svn/tree) may be dirtied.  The easiest thing to do is
-probably just to rm -rf $GIT_DIR/git-svn/tree and run 'rebuild'.
+probably just to rm -rf $GIT_DIR/git-svn/tree and run 'rebuild'.   You
+can avoid this problem entirely by using 'dcommit'.
 
 We ignore all SVN properties except svn:executable.  Too difficult to
 map them since we rely heavily on git write-tree being _exactly_ the
-- 
1.4.4.1.g22a08

[PATCH 3/3] git-svn: fix multi-init

[Eric Wong]

After the bugfix to connect to repositories where the user has
limited read permissions, multi-init was broken due to our
SVN::Ra connection being limited to working in a subdirectory;
so we now create a new Ra connection for init-ing branches
and another for tags

Along with that fix, allow the user to use the command-line
option flags for multi-init (--revision being the most notable;
but also --no-auth-cache, --config-dir, --username (for passing
to SVN), and --shared/--template for passing to git-init-db

Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
 git-svn.perl |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index d8d8716..3891122 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -124,7 +124,12 @@ my %cmd = (
 			  'no-graft-copy' => \$_no_graft_copy } ],
 	'multi-init' => [ \&multi_init,
 			'Initialize multiple trees (like git-svnimport)',
-			{ %multi_opts, %fc_opts } ],
+			{ %multi_opts, %init_opts,
+			 'revision|r=i' => \$_revision,
+			 'username=s' => \$_username,
+			 'config-dir=s' => \$_config_dir,
+			 'no-auth-cache' => \$_no_auth_cache,
+			} ],
 	'multi-fetch' => [ \&multi_fetch,
 			'Fetch multiple trees (like git-svnimport)',
 			\%fc_opts ],
@@ -3316,11 +3321,11 @@ sub libsvn_commit_cb {
 
 sub libsvn_ls_fullurl {
 	my $fullurl = shift;
-	$SVN ||= libsvn_connect($fullurl);
+	my $ra = libsvn_connect($fullurl);
 	my @ret;
 	my $pool = SVN::Pool->new;
-	my ($dirent, undef, undef) = $SVN->get_dir($SVN->{svn_path},
-						$SVN->get_latest_revnum, $pool);
+	my $r = defined $_revision ? $_revision : $ra->get_latest_revnum;
+	my ($dirent, undef, undef) = $ra->get_dir('', $r, $pool);
 	foreach my $d (keys %$dirent) {
 		if ($dirent->{$d}->kind == $SVN::Node::dir) {
 			push @ret, "$d/"; # add '/' for compat with cli svn
-- 
1.4.4.1.g22a08

Re: [PATCH 2/3] git-svn: documentation updates

[Steven Grimm]

Eric Wong wrote:
> Eliminate 'commit' from some places and plug 'dcommit' more.
> Also update the section --id (GIT_SVN_ID) usage since we
> have multi-init/multi-fetch now.
>   

In the spirit of the "should the -a option be the default in 
git-commit?" discussion... What are the chances that a future version of 
git-svn could change the "dcommit" command to "commit" and the current 
"commit" to something else? I know it's a historical artifact, but given 
that git-svn is (by definition) aimed at Subversion users who are 
probably used to running "svn commit", it seems like making "git-svn 
commit" be the thing you usually want to run would be a good thing. One 
less habit to unlearn.

Re: [PATCH 2/3] git-svn: documentation updates

[Eric Wong]

Steven Grimm <koreth@midwinter.com> wrote:
> Eric Wong wrote:
> >Eliminate 'commit' from some places and plug 'dcommit' more.
> >Also update the section --id (GIT_SVN_ID) usage since we
> >have multi-init/multi-fetch now.
> >  
> 
> In the spirit of the "should the -a option be the default in 
> git-commit?" discussion... What are the chances that a future version of 
> git-svn could change the "dcommit" command to "commit" and the current 
> "commit" to something else? I know it's a historical artifact, but given 
> that git-svn is (by definition) aimed at Subversion users who are 
> probably used to running "svn commit", it seems like making "git-svn 
> commit" be the thing you usually want to run would be a good thing. One 
> less habit to unlearn.

I've been considering something along those lines.  I'm interested in
renaming the current 'commit' command to something else (it still has
its uses), but I haven't figured out what to call it...

Also, something that can wrap (git commit && git svn dcommit) into one
step would be nice.

-- 

Re: [PATCH 2/3] git-svn: documentation updates

[Pazu]

Eric Wong <normalperson <at> yhbt.net> writes:

> Also, something that can wrap (git commit && git svn dcommit) into one
> step would be nice.

What I'd like to see is foreign systems integration for git pull/push. If git
had to use git-svn behind the curtains, so be it would be -very- nice if the
user could just use git pull/push.

-- Pazu

Re: [PATCH 2/3] git-svn: documentation updates

[Seth Falcon]

Eric Wong <normalperson@yhbt.net> writes:
> I've been considering something along those lines.  I'm interested in
> renaming the current 'commit' command to something else (it still has
> its uses), but I haven't figured out what to call it...

I think this would be a sensible change and will help new users get
started with git-svn.  

> Also, something that can wrap (git commit && git svn dcommit) into one
> step would be nice.

For my workflow, that wouldn't be all that useful.  I find that I
accumulate a few commits locally and then send them all to svn.  For
this workflow, what would be useful is if dcommit could understand a
command like:

    git svn dcommit remotes/git-svn..HEAD~2

Sometimes I realize I should have sent a stack of commits to svn, but
now have some newer commits that aren't quite ready on the head of my
branch.  

While the workaround is easy (create a new branch and dcommit from
it), I think there is a usability argument in that when one
sees an example like dcommit foo..bar, one expects all
the other magic to work.  I feel for this and accidentally committed a
few commits I didn't want to send.  If nothing else, perhaps git-svn
could error out and say, "hey, I don't do that".

Re: [PATCH 2/3] git-svn: documentation updates

[Eric Wong]

Pazu <pazu@pazu.com.br> wrote:
> Eric Wong <normalperson <at> yhbt.net> writes:
> 
> > Also, something that can wrap (git commit && git svn dcommit) into one
> > step would be nice.
> 
> What I'd like to see is foreign systems integration for git pull/push. If git
> had to use git-svn behind the curtains, so be it would be -very- nice if the
> user could just use git pull/push.

Both push and pull are git/bk/hg(?)-specific terms; most SVN users are
not accustomed to them.  Using 'pull' with git-svn has already been
discouraged for a while (since the introduction of dcommit); and
having a 'push' without a 'pull' would be very confusing.

I am interested in putting the .git/svn/*/info/url information into
.git/config, however (like modern remotes).

-- 

Re: [PATCH 2/3] git-svn: documentation updates

[Eric Wong]

Seth Falcon <sethfalcon@gmail.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> > I've been considering something along those lines.  I'm interested in
> > renaming the current 'commit' command to something else (it still has
> > its uses), but I haven't figured out what to call it...
> 
> I think this would be a sensible change and will help new users get
> started with git-svn.  
> 
> > Also, something that can wrap (git commit && git svn dcommit) into one
> > step would be nice.
> 
> For my workflow, that wouldn't be all that useful.  I find that I
> accumulate a few commits locally and then send them all to svn.  For
> this workflow, what would be useful is if dcommit could understand a
> command like:
> 
>     git svn dcommit remotes/git-svn..HEAD~2
> 
> Sometimes I realize I should have sent a stack of commits to svn, but
> now have some newer commits that aren't quite ready on the head of my
> branch.  
> 
> While the workaround is easy (create a new branch and dcommit from
> it), I think there is a usability argument in that when one
> sees an example like dcommit foo..bar, one expects all
> the other magic to work.  I feel for this and accidentally committed a
> few commits I didn't want to send.  If nothing else, perhaps git-svn
> could error out and say, "hey, I don't do that".

Aded to my ever-growing git-svn todo list.   Patches welcome :)

-- 

Re: [PATCH 2/3] git-svn: documentation updates

[Junio C Hamano]

Eric Wong <normalperson@yhbt.net> writes:

> Both push and pull are git/bk/hg(?)-specific terms; most SVN users are
> not accustomed to them.  Using 'pull' with git-svn has already been
> discouraged for a while (since the introduction of dcommit); and
> having a 'push' without a 'pull' would be very confusing.

I am not sure how 'push' side should be integrated, but I wish
people could simply update a branch that is managed by foreign
SCM interfaces such as git-svn and git-cvsimport with 'git fetch'
by saying that the remote URL points at a non-git "repository"
in remotes/ (or corresponding config).

git-cvsimport builds the git objects from the changeset without
using the working tree, and it would be very natural and simple
to integrate it into 'git fetch', pretending as if it is just a
funny transport.

If the interface uses the working tree to update the state from
foreign SCM, then integrating with git-fetch would be
inpractical.  I guess git-svn works that way?

Re: [PATCH 2/3] git-svn: documentation updates

[Eric Wong]

Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> 
> > Both push and pull are git/bk/hg(?)-specific terms; most SVN users are
> > not accustomed to them.  Using 'pull' with git-svn has already been
> > discouraged for a while (since the introduction of dcommit); and
> > having a 'push' without a 'pull' would be very confusing.
> 
> I am not sure how 'push' side should be integrated, but I wish
> people could simply update a branch that is managed by foreign
> SCM interfaces such as git-svn and git-cvsimport with 'git fetch'
> by saying that the remote URL points at a non-git "repository"
> in remotes/ (or corresponding config).

Ack on being able to use 'git fetch'.

> git-cvsimport builds the git objects from the changeset without
> using the working tree, and it would be very natural and simple
> to integrate it into 'git fetch', pretending as if it is just a
> funny transport.
> 
> If the interface uses the working tree to update the state from
> foreign SCM, then integrating with git-fetch would be
> inpractical.  I guess git-svn works that way?

git-svn only needs a working tree (hidden away in .git/svn/ and the user
should never see it) when it uses the command-line svn client.  If the
SVN:: libraries are available, then git-svn just uses an alternative
index like cvsimport.

--