darcs

Issue 1332 darcs add -r --boring sometimes skips boring files

Title darcs add -r --boring sometimes skips boring files
Priority bug Status resolved
Milestone Resolved in 2.10.0 HEAD
Superseder Nosy List darcs-devel, dmitry.kurochkin, kowey, thorkilnaur, twb, zooko
Assigned To
Topics

Created on 2009-01-27.17:26:56 by zooko, last changed 2012-11-10.23:41:10 by noreply.

Messages
msg7226 (view) Author: zooko Date: 2009-01-27.17:26:53
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
msg7241 (view) Author: twb Date: 2009-01-28.23:27:46
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/?
msg7633 (view) Author: kowey Date: 2009-04-09.12:05:49
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 :-)
msg8731 (view) Author: kowey Date: 2009-09-07.11:00:28
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
msg14500 (view) Author: galbolle Date: 2011-06-06.19:54:55
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.
msg14863 (view) Author: noreply Date: 2011-12-27.21:38:23
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
msg14870 (view) Author: noreply Date: 2011-12-27.22:23:39
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
msg16301 (view) Author: owst Date: 2012-11-06.12:27:09
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.
msg16313 (view) Author: galbolle Date: 2012-11-08.10:40:52
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.
msg16314 (view) Author: owst Date: 2012-11-08.10:47:12
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.
msg16315 (view) Author: galbolle Date: 2012-11-08.11:17:53
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!
msg16330 (view) Author: noreply Date: 2012-11-10.23:41:09
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
History
Date User Action Args
2009-01-27 17:26:56zookocreate
2009-01-28 23:27:48twbsetstatus: unread -> unknown
nosy: + twb
messages: + msg7241
2009-04-09 12:05:51koweysetpriority: bug
status: unknown -> needs-reproduction
title: darcs add -r --boring" doesn't -> darcs add -r --boring sometimes skips boring files
messages: + msg7633
nosy: kowey, zooko, simon, twb, thorkilnaur, dmitry.kurochkin
2009-08-25 17:40:01adminsetnosy: + darcs-devel, - simon
2009-08-27 14:16:29adminsetnosy: kowey, darcs-devel, zooko, twb, thorkilnaur, dmitry.kurochkin
2009-09-07 11:00:30koweysetstatus: needs-reproduction -> needs-implementation
nosy: kowey, darcs-devel, zooko, twb, thorkilnaur, dmitry.kurochkin
messages: + msg8731
2011-06-06 19:54:56galbollesetmessages: + msg14500
2011-12-27 21:36:27ganeshlinkpatch604 issues
2011-12-27 21:38:24noreplysetstatus: needs-implementation -> resolved
messages: + msg14863
resolvedin: 2.8.0
2011-12-27 22:23:40noreplysetstatus: resolved -> has-patch
messages: + msg14870
2012-11-06 12:27:10owstsetmessages: + msg16301
2012-11-08 10:40:53galbollesetmessages: + msg16313
2012-11-08 10:47:13owstsetmessages: + msg16314
2012-11-08 11:17:54galbollesetmessages: + msg16315
2012-11-10 23:41:10noreplysetstatus: has-patch -> resolved
messages: + msg16330
resolvedin: 2.8.0 -> 2.10.0 HEAD