On Sun, Jan 27, 2008 at 02:34:13PM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>
> >> but doesn't address the fact that we probably should remove files that
> >> aren't a part of the repository at in the first place.
> >
> > I am sorry, but I cannot begin to see what this commit tries to
> > accomplish. Yes, sure, there is an off-by-one error, and your commit
> > message says how that was fixed. But I miss a description what usage it
> > would affect, i.e. when this bug triggers.
> >
> > I imagine that you would be as lost as me, reading that commit message 6
> > months from now, trying to understand why that change was made.
>
> Likewise. The message has somewhat to be desired...
Agreed I'll resend with a improved message.
> In "struct exclude_stack", prep_exclude() and excluded(), the
> convention for a path is to express the length of directory part
> including the trailing slash (e.g. "foo" and "bar/baz" will get
> baselen=0 and baselen=4 respectively).
>
> The variable current and parameter baselen follow that
> convention in the codepath the patch touches.
>
> else {
> cp = strchr(base + current + 1, '/');
> if (!cp)
> die("oops in prep_exclude");
> cp++;
> }
> stk->prev = dir->exclude_stack;
> stk->baselen = cp - base;
>
> is about coming up with the next value for current (which is
> taken from stk->baselen) to dig one more level.
>
> If base="foo/a/boo" and current=4 (i.e. we are looking at
> "foo/"), at the point, scanning from (base+current) as Shawn
> Bohrer's patch suggests means the scan begins at "a/boo" to find
> the next slash. The existing code skips one letter ('a') and
> starts scanning from "/boo".
>
> The only case this microoptimization makes difference is when an
> input is malformed and has double-slash (i.e. path component
> whose length is zero), like "foo//boo".
Good catch, I didn't think of this case but this indeed will cause
the same issue.
> Perhaps the "oops part of the issue Johannes found" had a caller
> that feeds such an incorrect input?
Nope the problem Johannes Sixt was having was that he mistakenly ran
git clean -n /*foo
Now that isn't what he meant to do, but I figured it might be possible
that someone has their whole filesystem in a git repository, or maybe
is using some sort of chroot on their repository. Your malformed
paths guess is probably much more likely to occur.
--
Shawn
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
