When I do "darcs add -r --boring" then it skips the "docs/core"  
subdirectory because it thinks it is a boring old core file.

When I do "darcs add --boring docs/core" then it works.

---
Tahoe, the Least-Authority Filesystem -- http://allmydata.org
store your data: $10/month -- http://allmydata.com/?tracking=zsig

Hi Zooko,

On Tue, Jan 27, 2009 at 06:26:53AM +0000, Zooko wrote:
> When I do "darcs add -r --boring" then it skips the "docs/core"  
> subdirectory because it thinks it is a boring old core file.
> 
> When I do "darcs add --boring docs/core" then it works.

Would you care to write a test script (that currently fails) and send
a patch to the darcs-users list, placing it in bugs/?

We still need somebody to submit a test case for this:
http://wiki.darcs.net/index.html/RegressionTests

Zooko: please make your issue tracker submissions a tad more explicit.  Having
to think about which of the behaviours was the right one, and which was the
wrong one (wait, should it have added or refused to add?) is slows down triage :-)

Here's the test I wound up writing.  I'll submit this as a regression test.  I
think from there on, finding the source of the problem and fixing it will be
fairly straightforward, so I'll go ahead and mark this need-implementation.

darcs init      --repo R        # Create our test repos.
cd R
mkdir d
touch core f
# this is already known to work
darcs add --boring core f
darcs whatsnew > log
grep 'addfile ./f' log
grep 'addfile ./core' log
rm _darcs/patches/pending
# this fails for issue1332
darcs add -r --boring .
darcs whatsnew > log
grep 'addfile ./f' log
grep 'addfile ./core' log

There's a comment in the code (in Darcs/Commands/Add.hs, line 117) that
says "refusing to add boring files recursively". What should be darcs's
behaviour when the user types darcs add -r --boring dir?
-ignore --boring and warn? (1)
-add boring files/subdirs at any depth? (2)
-add boring immediate children but no more? (3)

I gather (3) is the option we want, please confirm.

The following patch sent by ganesh@earth.li updated issue issue1332 with
status=resolved;resolvedin=2.8.0 HEAD

* resolve issue1332: issue2054 was a dupe of this issue 
Ignore-this: 295a2c46f5d3179e429ad678e35fc541

The following patch sent by ganesh@earth.li updated issue issue1332 with
status=has-patch

* resolve issue1332: issue2054 was a dupe of this issue 
Ignore-this: 295a2c46f5d3179e429ad678e35fc541

This test actually doesn't pass (it didn't invalidate the index, causing
a serendipitous pass). We need to decide on the desired behaviour, as
listed by Florent in http://bugs.darcs.net/msg14500.

I've sent a patch fixing the test, and moving it back to failing.

I now think we want darcs add -r --boring to add all boring files,
whether explicitely passed or boring subpaths of an explicitely given
argument. (That is, behaviour 2).
- It is the simplest behaviour to explain
- It means that after "darcs add -r --boring", "darcs what -l --boring"
will not return any files to add, which is an important invariant
between add and whatsnew.

Behaviour 2 is certainly what I expected. 

If #3 was the default, one would have to manually traverse the repo's
directory structure, calling `darcs add -r --boring` at each level,
certainly inefficient!

One alternative to limit the number of files/dirs presented to the user
(which presumably is why #3 is desirable), is to give add an interactive
option, which would allow a user to say no to descending into a given
subdir.

My argument for #3 is that #2 is easier to emulate using find, but it
does not hold much water.So #2 is the consensus, rejoice!

The following patch sent by Florent Becker <florent.becker@ens-lyon.org> updated issue issue1332 with
status=resolved;resolvedin=2.10.0 HEAD

* Resolve issue1332 for good 
Ignore-this: 7b8c718710d850e98c0eabfa5f9b1ef0

The following patch sent by Ben Franksen <benjamin.franksen@helmholtz-berlin.de> updated issue issue1332 with
status=resolved;resolvedin=2.12.0 HEAD

* renamed no longer failing test for resolved issue1332 
Ignore-this: 93fb302e7c46ef9df116b39d42ae25c7