threads / patch / 3422

patchgit-ls-files: Fix, document, and add test for --error-unmatch option.

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

## tl;dr

2 messages between Feb 21, 2006 and Feb 22, 2006. Diffs are folded; open one to read it.

replies: 1people: 2as markdown or json

Carl Worth· Feb 21, 2006, 20:48 UTC · lore
---
 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
Show changes to 3 files +33 −0

Documentation/git-ls-files.txt, ls-files.c, t/t3020-ls-files-error-unmatch.sh

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
Junio C Hamano· Feb 22, 2006, 01:59 UTC · re: Carl Worth · lore

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

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.

← back to recent threads