Re* [take 2] git send-email updates

From

Junio C Hamano <gitster@pobox.com>

Date

Nov 13, 2008, 00:01 UTC

Message-ID

<7vfxlwlcid.fsf_-_@gitster.siamese.dyndns.org>

In-Reply-To

<7vk5b9x0kj.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

> Actually, "send-email --format-patch master..fixes Documentation/" may be
> a useful command to send out only documentation fixes.  For such a usage,
> Documentation/ should not be taken as a maildir.  If we would want to
> support such usage (and I'd say why not), a token can fall into one (or
> two) of three categories:
>
>     - can it be a rev?
>
>     - is it a tracked path (either blob or a leading dir)?
>
>     - is it a file/dir that is not tracked?
>
> The first two would be format-patch candidate.  The last one is the
> traditional mail source.  Because the latter two are disjoint set, and
> because it does not matter if you have a tracked file 'master' and a
> branch 'master' in your repo (either will be passed to format-patch
> anyway), the actual disambiguity is reduced, but it still is different
> from what you have in your patch, I suspect.
>
> As to options, how about doing this:
>
>     --no-format-patch means never ever run format-patch, behave exactly as
>     before;
>
>     --format-patch means what you have in your patch.  guess and favor 
>     format-patch parameter when ambiguous;
>
>     without either option, guess and favor mbox/maildir but still run
>     format-patch if remaining parameters and options need to
>     (e.g. "send-email my-cover-letter origin/master..master" will find
>     my-cover-letter which is not tracked and take it as mbox, and grab
>     patches from commits between origin/master..master, and send all of
>     them).

 git-send-email.perl |   35 +++++++++++++++++++++++++++++++----
 1 files changed, 31 insertions(+), 4 deletions(-)

diff --git c/git-send-email.perl w/git-send-email.perl
index 6f5a613..9aa3500 100755
--- c/git-send-email.perl
+++ w/git-send-email.perl
@@ -152,7 +152,7 @@ if ($@) {
 
 # Behavior modification variables
 my ($quiet, $dry_run) = (0, 0);
-my $format_patch;
+my $format_patch = 'unspecified';
 my $compose_filename = $repo->repo_path() . "/.gitsendemail.msg.$$";
 
 # Variables with corresponding config settings
@@ -243,6 +243,15 @@ unless ($rc) {
     usage();
 }
 
+if ($format_patch && $format_patch eq 'unspecified') {
+	# No --format-patch nor --no-format-patch on the command line
+	$format_patch = 0;
+} elsif (!$format_patch) {
+	$format_patch = undef;
+} else {
+	$format_patch = 1;
+}
+
 # Now, let's fill any that aren't set in with defaults:
 
 sub read_config {
@@ -374,11 +383,27 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
 # returns 1 if the conflict must be solved using it as a format-patch argument
 sub check_file_rev_conflict($) {
 	my $f = shift;
+
+	if (!defined $format_patch) {
+		# The command line explicitly forbids acting as a wrapper
+		return 0;
+	}
+
+	# If it is a tracked path it can't be tracking the e-mails you
+	# are going to send out to describe the change to this repository.
+	eval {
+		$repo->command(['ls-files', '--error-unmatch', $f],
+			       { STDERR => 0 });
+	};
+	if (!$@) {
+		return 1;
+	}
+
+	# Can it be interpreted as a rev?
 	try {
 		$repo->command('rev-parse', '--verify', '--quiet', $f);
-		if (defined($format_patch)) {
-			print "foo\n";
-			return $format_patch;
+		if ($format_patch) {
+			return 1;
 		}
 		die(<<EOF);
 File '$f' exists but it could also be the range of commits
@@ -408,6 +433,8 @@ while (my $f = pop @ARGV) {
 		closedir(DH);
 	} elsif ((-f $f or -p $f) and !check_file_rev_conflict($f)) {
 		push @files, $f;
+	} elsif (!defined $format_patch) {
+		die("--no-format-patch was given but $f is not a valid send-email argument");
 	} else {
 		push @rev_list_opts, $f;
 	}