git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/3] builtin-add: fix exclude handling
Date: Tue, 9 Mar 2010 17:48:15 -0500	[thread overview]
Message-ID: <20100309224815.GB25265@sigill.intra.peff.net> (raw)
In-Reply-To: <7vzl2s4fcy.fsf@alter.siamese.dyndns.org>

On Mon, Mar 01, 2010 at 12:26:37AM -0800, Junio C Hamano wrote:

>  - "git add ignored-pattern.o", i.e. the pathspec exactly matches but is
>    ignored by the traversal.
> 
> For the former, the function immediately errored out.  The latter were
> queued in the dir structure and later used to give an error message with
> "use -f if you really mean it" advice.
> 
> e96980e (builtin-add: simplify (and increase accuracy of) exclude
> handling, 2007-06-12) somehow lost the latter.  This adds the logic back,
> but with a bit of twist, as the code after e96980e uses collect_ignored
> option that does half the necessary work during the traversal.

I'm not sure that logic is accurate. The "increase accuracy" part of
e96980e was about the fact that COLLECT_IGNORED _knows_ something is
ignored, but builtin-add's prune_directory has to just _guess_ about it.

And I think your new code may have similar problems.  Look at the
failing test in t0050 (the one you tweaked in patch 1/3).  Before this
patch, it silently fails to add. Which is a bug, of course, but not this
one. But after this patch, we say "Oh, CamelCase was excluded, use -f,
etc". But that's not true. We are just making a guess after the fact
about why it wasn't included.

Now I am slightly hesitant to use that as an example, because it clearly
was also broken _before_ your patch. So it may be that the behavior it
exhibits (a pathspec not showing up as used, but the file exists and was
_not_ ignored) shouldn't ever happen for other cases.  I'm not sure,
which makes me a little nervous about the change. But I would be willing
to accept "it seems to work, so let's go with it for now and see if
anybody complains" if you want to try that.

But also:

> +		/* Existing file?  We must have ignored it */
> +		if (file_exists(match)) {
> +			int len = strlen(match);
> +			int i;
> +			for (i = 0; i < dir->ignored_nr; i++)
> +				if (dir->ignored[i]->len == len &&
> +				    !memcmp(dir->ignored[i]->name, match, len))
> +					break;
> +			if (dir->ignored_nr <= i)
> +				dir_add_ignored(dir, match, strlen(match));
> +			continue;
> +		}
> +		die("pathspec '%s' did not match any files", match);

Is that memcmp right? If I have something like:

  echo subdir >.gitignore
  git add 'sub*'

shouldn't it also say "Sorry, subdir [or sub*] was ignored"? But it
doesn't actually get added to the exclude list, and we get "pathspec did
not match any files", which is not quite true.

-Peff

      reply	other threads:[~2010-03-09 22:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-01  8:26 [PATCH 3/3] builtin-add: fix exclude handling Junio C Hamano
2010-03-09 22:48 ` Jeff King [this message]

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=20100309224815.GB25265@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).