Skip to content
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 ignore support to ipfs add #653

Closed
lgarron opened this issue Jan 25, 2015 · 12 comments
Closed

Add ignore support to ipfs add #653

lgarron opened this issue Jan 25, 2015 · 12 comments
Labels
exp/novice Someone with a little familiarity can pick up kind/bug A bug in existing code (including security flaws) topic/commands Topic commands

Comments

@lgarron
Copy link
Contributor

lgarron commented Jan 25, 2015

I do not ever plan to add .DS_Store files into an object, but it's annoying to delete them manually (and Finder.app always puts them back if you're viewing the folder).

If would be nice to have one of the following:

  • A --ignore flag for ipfs add.
  • Support for .ipfsignore files (either within the node, or globally).
@whyrusleeping
Copy link
Member

Ive been wanting this myself too, if i try to do ipfs add -r / i dont want my /dev or /tmp directories added. And i probably also dont want ~/.go-ipfs in that too... might get weird.

@btc
Copy link
Contributor

btc commented Jan 25, 2015

+1 for .ipfsignore

@jbenet jbenet added kind/bug A bug in existing code (including security flaws) topic/commands Topic commands difficulty: easy labels Mar 28, 2015
@gatesvp
Copy link
Contributor

gatesvp commented Apr 21, 2015

I love this idea. For anyone who's a git user, there's a certain intuition to having an .ipfsignore flag.

That stated, I think this may actually be a pair of features.

  1. Ignore any hidden files by default (files/folder beginning with .).
  2. Add the ability to respect an .ipfsignore file. Something like the git one (http://git-scm.com/docs/gitignore).

Part 1 actually seems like a rational default in most OSes. We'll need to add a -f for explicit inclusion of these files.

Part 2 would need some consensus on where to store the .ipfsignore file. In git, this makes sense to store at the root of a repo. Given that I can run ipfs add basically anywhere on my computer, it's not clear if I want to look at some base file or check the values in the folder I'm currently adding.

@whyrusleeping
Copy link
Member

re Part 2, i think both looking in $IPFS_PATH/.ipfsignore and the current directory would be a good way to do it

@jbenet
Copy link
Member

jbenet commented Apr 28, 2015

@gatesvp agreed on the two parts. for part 1, i think maybe --hidden could include all of them. so:

> ls
.h1
.h2
f1
f2
> ipfs add -r .
added <> f1 
added <> f2 
> ipfs add .h1
error: .h1 is a hidden file. 
> ipfs add --hidden .h1
added <> .h1
> ipfs add --hidden -r .
added <> .h1
added <> .h2
added <> f1
added <> f2

for part 2, i think we should follow git's idea: recursively walk up and apply all .ipfsignores. (at least i think it does that? pls correct me). and +1 on using a default one in $IPFS_PATH/.ipfsignore.

@gatesvp
Copy link
Contributor

gatesvp commented May 2, 2015

So I am part way through this, and have just realized that Windows has a different notion of a hidden file and folder. "Hidden" is actually an attribute of the file rather than just a . at the beginning of the name.

It looks like git in Windows actually makes the .git file hidden.

My current plan is to make Windows support both the attribute and the dot prefix by default. Using the . as the first character in Windows is really rare and it hopefully makes things portable.

Thoughts? Concerns?

@whyrusleeping
Copy link
Member

that sounds pretty good to me

@gatesvp
Copy link
Contributor

gatesvp commented May 6, 2015

Alright, quick update after a fun / busy weekend

Good news:

Bad news:

  • The imported go-git-ignore is a little flaky because it doesn't handle encodings. Obviously an issue on a windows machine.
  • I'm not 100% clear on $IPFS_PATH/.ignore. Do we use this somewhere else (flatfs)? Or is this just an invention for this run?
  • My code currently includes a straight pointer to go-git-ignore, I know that we normally import this as a go-dep but I'm not clear on the methodology.

@gatesvp
Copy link
Contributor

gatesvp commented May 6, 2015

Arg.. still one bug at the end of this gist: https://gist.github.com/gatesvp/d9e26a391064ee50ab7b
But it's too late in the day for me to fix this.

In any case, I still appreciate inputs on the rest of the stuff :)

@whyrusleeping
Copy link
Member

dont worry about vendoring, i can manage that for you. (or, when i fail horribly at figuring out godeps, jbenet can do it for you)

@jbenet
Copy link
Member

jbenet commented May 6, 2015

@gatesvp great to hear!

I'm not 100% clear on $IPFS_PATH/.ignore. Do we use this somewhere else (flatfs)? Or is this just an invention for this run?

The idea is that we'd have one central location (similar to ~/.gitconfig) to add another .ipfsignore file to ignore things you always want ignored (e.g. if i always want to ignore .DS_Store on osx, even if i ask for --hidden files.)

I think it should be $IPFS_PATH/.ipfsignore (not .../.ignore) so the filename is consistent everywhere.

My code currently includes a straight pointer to go-git-ignore, I know that we normally import this as a go-dep but I'm not clear on the methodology.

try:

> make vendor

it may complain about not having things, you may have to godep restore them.

(or, when i fail horribly at figuring out godeps, jbenet can do it for you)

Yeah i can fix it.

(LMVTFY :) )

(vendoring came up: 2/100)

@rht
Copy link
Contributor

rht commented Sep 3, 2015

Can be closed because it's a duplicate of #1451

@jbenet jbenet closed this as completed Sep 3, 2015
@RichardLitt RichardLitt added the exp/novice Someone with a little familiarity can pick up label Feb 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/novice Someone with a little familiarity can pick up kind/bug A bug in existing code (including security flaws) topic/commands Topic commands
Projects
None yet
Development

No branches or pull requests

7 participants