git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Jeff King <peff@peff.net>
Cc: "Ismail Dönmez" <ismail@pardus.org.tr>,
	"Junio C Hamano" <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: [ANNOUNCE] GIT 1.5.4-rc3
Date: Sat, 12 Jan 2008 14:01:09 +0100	[thread overview]
Message-ID: <4788BA15.3050804@lsrfire.ath.cx> (raw)
In-Reply-To: <20080112090432.GA6134@coredump.intra.peff.net>

Jeff King schrieb:
> Thus allocating "seen" based upon just argc is wrong, since
> if argc == 0, then we still have one pathspec, the prefix,
> but we don't allocate any space in "seen".

Yes, all the other callers count the number of elements in pathspec
and allocate seen accordingly.  We could do that.  Or we could
extend match_pathspec() to allow seen to be a NULL pointer, for
those cases where this result isn't needed.

This patch is for discussion, only, because it touches central,
non-buggy code and where in bugfix only mode.  And I'm not really
sure git-clean ignoring non-matching pathspecs (as it does now,
even without this patch) is really what we want.

 builtin-clean.c |    8 +-------
 dir.c           |   26 ++++++++++++++++----------
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/builtin-clean.c b/builtin-clean.c
index 6cad8ea..40d976c 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -35,7 +35,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
 	const char *path, *base;
 	static const char **pathspec;
 	int prefix_offset = 0;
-	char *seen = NULL;
 	struct option options[] = {
 		OPT__QUIET(&quiet),
 		OPT__DRY_RUN(&show_only),
@@ -89,9 +88,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
 	read_directory(&dir, path, base, baselen, pathspec);
 	strbuf_init(&directory, 0);
 
-	if (pathspec)
-		seen = xmalloc(argc);
-
 	for (i = 0; i < dir.nr; i++) {
 		struct dir_entry *ent = dir.entries[i];
 		int len, pos, matches;
@@ -125,9 +121,8 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
 			continue;
 
 		if (pathspec) {
-			memset(seen, 0, argc);
 			matches = match_pathspec(pathspec, ent->name, ent->len,
-						 baselen, seen);
+						 baselen, NULL);
 		} else {
 			matches = 0;
 		}
@@ -165,7 +160,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
 			unlink(ent->name);
 		}
 	}
-	free(seen);
 
 	strbuf_release(&directory);
 	return 0;
diff --git a/dir.c b/dir.c
index 3e345c2..6af70ac 100644
--- a/dir.c
+++ b/dir.c
@@ -88,32 +88,38 @@ static int match_one(const char *match, const char *name, int namelen)
 
 /*
  * Given a name and a list of pathspecs, see if the name matches
- * any of the pathspecs.  The caller is also interested in seeing
- * all pathspec matches some names it calls this function with
- * (otherwise the user could have mistyped the unmatched pathspec),
- * and a mark is left in seen[] array for pathspec element that
- * actually matched anything.
+ * any of the pathspecs.
+ * If the caller is interested in which of the pathspecs matched,
+ * seen needs to point to a char array with as many members as there
+ * are pathspecs.  A mark is left at the nth element of the nth
+ * pathspec matched the name.  The marks are not reset, so the
+ * caller can check, after matching a list of files, if there are
+ * any unmatched pathspecs (which might have been mistyped).
  */
 int match_pathspec(const char **pathspec, const char *name, int namelen, int prefix, char *seen)
 {
-	int retval;
-	const char *match;
+	int retval = 0;
 
 	name += prefix;
 	namelen -= prefix;
 
-	for (retval = 0; (match = *pathspec++) != NULL; seen++) {
+	while (*pathspec) {
+		const char *match = *pathspec++;
 		int how;
-		if (retval && *seen == MATCHED_EXACTLY)
+
+		if (retval && seen && *seen == MATCHED_EXACTLY)
 			continue;
+
 		match += prefix;
 		how = match_one(match, name, namelen);
 		if (how) {
 			if (retval < how)
 				retval = how;
-			if (*seen < how)
+			if (seen && *seen < how)
 				*seen = how;
 		}
+		if (seen)
+			seen++;
 	}
 	return retval;
 }

  parent reply	other threads:[~2008-01-12 13:02 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-12  7:11 [ANNOUNCE] GIT 1.5.4-rc3 Junio C Hamano
2008-01-12  7:26 ` Ismail Dönmez
2008-01-12  7:34   ` Junio C Hamano
2008-01-12  7:47     ` Ismail Dönmez
2008-01-12  8:04       ` Junio C Hamano
2008-01-12  9:04       ` Jeff King
2008-01-12  9:05         ` Jeff King
2008-01-12 11:10         ` valgrind test script integration Jeff King
2008-01-12 11:36           ` Jeff King
2008-01-12 17:10             ` Johannes Schindelin
2008-01-12 18:12               ` Jeff King
2008-01-12 13:01         ` René Scharfe [this message]
2008-01-12 13:10         ` [ANNOUNCE] GIT 1.5.4-rc3 Ismail Dönmez
2008-01-12 16:57         ` Johannes Schindelin
2008-01-12 18:09           ` Jeff King
2008-01-12 19:09         ` Junio C Hamano
2008-01-12 14:24 ` Roger C. Soares
2008-01-12 19:13   ` Junio C Hamano
     [not found] ` <7vsl13wmas.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
2008-01-13 14:41   ` Steffen Prohaska
2008-01-21  2:37 ` [ANNOUNCE] GIT 1.5.4-rc4 Junio C Hamano
     [not found]   ` <7vsl0r3nvc.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
2008-01-21 22:22     ` Steffen Prohaska
     [not found]       ` <BB330DC7-9F38-4D41-85A2-D475701B6083-wjoc1KHpMeg@public.gmane.org>
2008-01-22  1:21         ` Johannes Schindelin
     [not found]           ` <alpine.LSU.1.00.0801220121300.5731-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org>
2008-01-22  5:50             ` Steffen Prohaska
2008-01-28 10:56   ` [ANNOUNCE] GIT 1.5.4-rc5 Junio C Hamano
2008-01-28 18:38     ` Jeff King
2008-01-29  0:36       ` Gustaf Hendeby
2008-01-29  1:25       ` Junio C Hamano
2008-01-29  1:29         ` Jeff King
2008-01-29  6:06     ` Steffen Prohaska

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4788BA15.3050804@lsrfire.ath.cx \
    --to=rene.scharfe@lsrfire.ath.cx \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ismail@pardus.org.tr \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).