Adam Spiers <> writes:

> I already have a rough fix for the second issue, but I wanted to
> solicit feedback on the appropriate UI changes before proceeding much
> further.  Does something like the below patch seem reasonable, modulo
> the lack of tests?  In case the UI changes I am proposing are not
> clear from the patch, here's some example output from running it
> inside a clone of the git source tree:
>     $ git check-ignore -v -n foo.tar.{gz,bz2}
>     .gitignore:203:*.tar.gz foo.tar.gz
>     ::      foo.tar.bz2
> So the number of output fields does not change depending on whether
> the pattern matches or not, and any caller can determine whether it
> does simply by checking whether the first field is non-empty.

Haven't looked at the proposed patch very carefully, but the design
looks sound.  The above output screams "empty! nothing!", and I do
not think there is any other way :: will show up in that position.

> Also, does it make sense to write a new test to accompany the fix to
> the first (streaming) issue?

Would it be tricky to write safely not to get stuck?  You feed one
line, stop feeding, while checking that the output has arrived, and
then kill the whole thing?  Feels somewhat yucky, but sounds doable.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to