On Wed, 07 Jul 2021 19:14:25 +0200, Stefan Sperling wrote:

> It will print nothing and add nothing.
>
> Raising an error is a bad idea since the ignored file would usually be
> picked up by some wildcard expression and we still want that case to
> succeed ('cvs add *' is likely what robert actually did).

That makes sense for the general case.  What I was wondering about
is whether it would be best to have some kind of output if "got
add" adds no files at all.  Otherwise, the user will think it
succeeded when it may not have.

> One option is to list ignored files as such, using a new status code.
> I've already played with this. An earlier version of my patch printed this:
>
>  $ got add foo.core
>  I foo.core
>  $
>
> This tells the user why foo.core wasn't added, which on the surface
> seems much better than the behaviour implemented by my current patch,
> which looks like this:
>
>  $ got add foo.core
>  $

That looks good to me.

> But unless we special-case things the recursive case would then also
> report ignored files. Which would look like this:
>
>  $ got add -R .
>  A README
>  I foo.core
>  I obj/bar.o
>  I obj/foo.o
>  A src/foo.c
>  A src/bar.c
>  I src/bar.c.orig
>  $
>
> Whereas the current output just would be:
>
>  $ got add -R .
>  A README
>  A src/foo.c
>  A src/bar.c
>  $
>
> So this new output for -R would potentially display many more ignored files
> than added files which might not be desirable. We could perhaps collapse
> ignored directories to make this less of an issue:

Or perhaps just not output ignored files for recursive add by
default?  A verbose flag could be used if you really want to make
it possible to see all ignored files.

I don't want to derail discussion of the current diff so we can
discuss this further after you commit it.

 - todd