threads / patch / 10673

patchgit-commit.sh: Fix usage checks regarding paths given when they do not make sense

Subject: [PATCH] git-commit.sh: Fix usage checks regarding paths given when they do not make sense

## tl;dr

2 messages between Nov 5, 2007 and Nov 5, 2007. Diffs are folded; open one to read it.

replies: 1people: 2as markdown or json

Björn Steinbrink· Nov 5, 2007, 19:36 UTC · lore

The checks that looked for paths given to git-commit in addition to --all or --interactive expected only 3 values, while the case statement actually provides 4, so the check was never triggered.

The bug was introduced in 6cbf07efc5702351897dee4742525c9b9f7828ac when the case statement was extended to handle --interactive.

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
 git-commit.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
Show changes to git-commit.sh +2 −2
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..d4471ff 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -282,9 +282,9 @@ unset only
 case "$all,$interactive,$also,$#" in
 *t,*t,*)
 	die "Cannot use -a, --interactive or -i at the same time." ;;
-t,,[1-9]*)
+t,,,[1-9]*)
 	die "Paths with -a does not make sense." ;;
-,t,[1-9]*)
+,t,,[1-9]*)
 	die "Paths with --interactive does not make sense." ;;
 ,,t,0)
 	die "No paths with -i does not make sense." ;;
-- 
1.5.3.5.561.g140d-dirty
Junio C Hamano· Nov 5, 2007, 21:39 UTC · re: Björn Steinbrink · lore

Re: [PATCH] git-commit.sh: Fix usage checks regarding paths given when they do not make sense

Björn Steinbrink <B.Steinbrink@gmx.de> writes:
Show 6 quoted lines
> The checks that looked for paths given to git-commit in addition to
> --all or --interactive expected only 3 values, while the case statement
> actually provides 4, so the check was never triggered.
>
> The bug was introduced in 6cbf07efc5702351897dee4742525c9b9f7828ac when
> the case statement was extended to handle --interactive.
Gaah, and thanks.

We really should have "negative" tests to catch this kind of breakage in our testsuite. People when inventing new features are eager to write tests to show off the new stuff works, but not many people are careful enough to add tests to demonstrate the commands properly catch user errors such as borked command line options.

← back to recent threads