-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for hidden files and .ipfsignore file #1232
Conversation
…ate .ipfsignore files
…w methods on the struct
fix ipfs add to ensure that we are checking parent paths for appropriate .ipfsignore files [ reworded to conform to commit msg guidelines ]
ipfs#1204 [ reworded to conform to commit msg guidelines ]
Basic params are a struct and addFile/addDir are now methods on the struct [ reworded to conform to commit msg guidelines ]
@gatesvp thanks! btw-- you can just |
Thank you, that makes sense. Still a git newbie, so I'm always a little hesitant to do anything that involves a |
Testing all the commits |
Tests don't pass before the last commit -- i'm just going to squash everything. |
Squashed over at gatesvp-squashed |
Ok, @gatesvp this is looking good. This doesn't have any tests though. I can't merge this without tests because this is a very important change of functionality. It will likely break right away without tests. We need at least some sharness tests for it so that we both (a) make sure it does what we expect it to, and (b) catches any problems. It may be worth taking a look at git's |
maybe can see if others who want this can help write tests. |
So I actually support your desire for tests 100%. Honestly would have been easier to write with test file to work off of :) I basically built this convoluted folder of hidden files and However, it doesn't look like the CLI commands have any I'll fire up my Linux Box and try building some extra tests in |
Update on this item. I have some basic tests working on my local dev box. However, I am trapped on one set of tests. I am trying to test that On Ubuntu it looks like the test creates this My code tries to walk the parent folders by splitting out the components and then gluing them back together one at a time with I will keep tinkering with it, but if we have a known workaround here, it would be appreciated. |
So, a little bit more thought on this: I think we should respect 1) the global An example of 3:
The let me know what you think, and also lets gets @jbenet's input. |
sounds like it's not dealing with spaces correctly. to catch errors like this is precisely why the trash folders have a space. (thanks git and @chriscool)
i think the way @gatesvp has it -- which is 1-3 + parent dirs -- is the right way. the way git does it, too. "doing parent dirs" should go along with "doing child dirs". it's a symmetric relationship. otherwise tool will behave differently depending on what dir in hierarchy you run it. to give an example,
should all ignore the same files, not be dependent on where you started the call.. that'd be super confusing. |
Oh, i agree with that. I thought that (using your example) it would look at 'foo's parent for an ipfsignore file. |
Key difference here is that What I have right now is actually recursive "to the root". There's no check of current working directory (CWD) So with respect to @whyrusleeping 's notation, I have 1 & 3, but not really 2 (CWD). If you have
It doesn't sound like "to the root" is really desired behaviour... but it feels like all of the options are kind of awkward.
(extra note, it is the "to the root" functionality that is failing in my sharness tests) |
yeah, kill my current working directory idea, that was bad. i'm quite skeptical about traveling to the root... youre right about unexpected behaviour if |
This will let us handle functionality like ignored files (#1232) without needing to alter the adder API or chunk/trickle files that we know we're going to ignore ahead of time. I considered sticking with nOut *dag.Node instead of ignore bool to give folks more flexibility (e.g. "use nOut instead of chunking/trickling that path yourself"), but I can't think of an easy way to distinguish "please ignore this path" from "please handle this path using your usual chunking/trickling" if we're returning just nOut and err. So this callback just returns a Boolean distinguishing "please ignore" from "please chunk/trickle as usual", and we can add an additional nOut return if we find a use case for a callback-supplied substitute node.
@gatesvp would love to have this in, any update on tests here? |
Yes, I am still alive and think I have it figured out :) Testing it on my windows box right now, will test some more tonight. And On Tue, Jun 30, 2015 at 11:20 AM, Juan Batiz-Benet <notifications@github.com
|
There were the following issues with your Pull Request
Guidelines are available to help. Your feedback on GitCop is welcome on this issue This message was auto-generated by https://gitcop.com |
So that last changeset adds the required tests and also fixes an issue I found while building out the tests. Namely that As it stands, that last check-in is a little wild because I am pulling in two months of work and trying to rebase over top. @jbenet this may need some manual intervention. The only key files changed in that last set were |
Should resolve issue #653.
Should incorporate all of the feedback from the previous PR that was closed.
Manually tested / built on Linux and Windows with a set of folders of my own design.