[PATCH] git-ls-files: Fix, document, and add test for --error-unmatch option.

[PATCH] git-ls-files: Fix, document, and add test for --error-unmatch option.

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 3466 bytes --]

---

 Junio,

 I'm still not sure what the easiest way is for me to provide changes
 to you. I've been doing it here on the list, like with the current
 message. But would it be easier for me to send pull requests?

 For example, with the git-clone failure cleanup I recently did, it
 seems the new test case I wrote didn't land in your tree. And since
 we went through patches in the mail, the missing commit wasn't
 obvious to me, (I checked and noticed with git-cherry, but it seems
 it would have been much easier if we were working with the same
 commit objects).

 If it would help you for me to publish a tree, just let me know how
 best to organize it, (I didn't see any comments on that in
 Documentation/SubmittingPatches).

 For now, I've made a tree available at:

	git://git.freedesktop.org/~cworth/git

 It contains two branches of interest:

	ls-files-error-unmatch	# The patch in this mail
	clone-fail-cleanup	# The missing test case mentioned above

 as well as the version I've currently got installed and am running:

	cworth			# The merge of those two with master

 Let me know if any other organization would be more helpful, and how
 to best make pull requests if desired.

 Thanks,

 -Carl

 Documentation/git-ls-files.txt    |    5 +++++
 ls-files.c                        |    1 +
 t/t3020-ls-files-error-unmatch.sh |   27 +++++++++++++++++++++++++++
 3 files changed, 33 insertions(+), 0 deletions(-)
 create mode 100755 t/t3020-ls-files-error-unmatch.sh

d7e8e6b2bb34db12c4fc1e4f83810db50b7ddf69
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index fe53412..28dc533 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -14,6 +14,7 @@ SYNOPSIS
 		[-x <pattern>|--exclude=<pattern>]
 		[-X <file>|--exclude-from=<file>]
 		[--exclude-per-directory=<file>] 
+		[--error-unmatch]
 		[--full-name] [--] [<file>]\*
 
 DESCRIPTION
@@ -72,6 +73,10 @@ OPTIONS
 	read additional exclude patterns that apply only to the
 	directory and its subdirectories in <file>.
 
+--error-unmatch::
+	If any <file> does not appear in the index, treat this as an
+	error (return 1).
+
 -t::
 	Identify the file status with the following tags (followed by
 	a space) at the start of each line:
diff --git a/ls-files.c b/ls-files.c
index df93cf2..27059e2 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -758,6 +758,7 @@ int main(int argc, const char **argv)
 				continue;
 			error("pathspec '%s' did not match any.",
 			      pathspec[num] + prefix_offset);
+			errors++;
 		}
 		return errors ? 1 : 0;
 	}
diff --git a/t/t3020-ls-files-error-unmatch.sh b/t/t3020-ls-files-error-unmatch.sh
new file mode 100755
index 0000000..d55559e
--- /dev/null
+++ b/t/t3020-ls-files-error-unmatch.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Carl D. Worth
+#
+
+test_description='git-ls-files test for --error-unmatch option
+
+This test runs git-ls-files --error-unmatch to ensure it correctly
+returns an error when a non-existent path is provided on the command
+line.
+'
+. ./test-lib.sh
+
+touch foo bar
+git-update-index --add foo bar
+git-commit -m "add foo bar"
+
+test_expect_failure \
+    'git-ls-files --error-unmatch should fail with unmatched path.' \
+    'git-ls-files --error-unmatch foo bar-does-not-match'
+
+test_expect_success \
+    'git-ls-files --error-unmatch should succeed eith matched paths.' \
+    'git-ls-files --error-unmatch foo bar'
+
+test_done
+1
-- 
1.2.2.g73be-dirty


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] git-ls-files: Fix, document, and add test for --error-unmatch option.

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

>  I'm still not sure what the easiest way is for me to provide changes
>  to you. I've been doing it here on the list, like with the current
>  message. But would it be easier for me to send pull requests?

You can decide what is easier for _you_ ;-).

But for me, emailed patches are easier to work on than pull
requests.  I will need to read and understand most of the
changes anyway, unless the change is to an isolated corner of
the system that would affect only one class of users and
breakage will be noticed either immediately or can be left
broken if nobody uses that (e.g. things like contrib/ and some
foreign SCM interfaces).  I would like others on the list to be
able to review the same changes that might hit my tree and
provide extra sets of eyeballs to spot things I might miss
myself alone.

>  For example, with the git-clone failure cleanup I recently did, it
>  seems the new test case I wrote didn't land in your tree.

Sorry, I think I just forgot to apply that one.  I still have
the message so no need to resend.  Thanks for reminding.