Skip to content
This repository has been archived by the owner on Nov 14, 2023. It is now read-only.

Everything excluded when using exclude-all-then-add-some .gitignore #30

Open
nabijaczleweli opened this issue Aug 29, 2016 · 9 comments

Comments

@nabijaczleweli
Copy link
Contributor

See for example this repo

I hacked at it but failed to make it work :v

@nabijaczleweli
Copy link
Contributor Author

Any updates on this?

@kbknapp
Copy link
Owner

kbknapp commented Sep 16, 2016

@nabijaczleweli Sorry not yet, I've been spending my limited spare time on clap. I'm hoping to get some of this looked at early next week.

@rabisg
Copy link

rabisg commented Dec 29, 2016

Hi,
I was playing around with the code trying to fix this. I thought I'll just note down my observations:

  • This problem actually originates at gitignore.rs repo. I've raised a bug for this case.
  • Ideally shouldn't the get_all_files fn be gitignore.get_included_files().filter(|fp| !exclude.contains(fp)). The only thing would be it might not honor follow_links
  • I was wondering what's the point of having the follow_links options? It looks like the current code wouldn't handle circular links (upstream gitignore wouldn't either). Also symlinks might point outside the current git directory in which case does it make sense to follow it? And if a file is in the repo but is a symlink won't it get included by the non-symlinked path?

Just my $0.02. Please tell me what you think

@kbknapp
Copy link
Owner

kbknapp commented Dec 29, 2016

I was wondering what's the point of having the follow_links options?

I can't remember why I originally added it, but it wasn't really meant to do anything too sophisticated like detecting circular links. In all honesty we could probably remove that options and still be fine.

@rabisg
Copy link

rabisg commented Dec 30, 2016

In that case I can send a pull request to remove this option and replace get_all_files which uses gitignore.get_included_files. Should I go ahead and do that?

@kbknapp
Copy link
Owner

kbknapp commented Jan 30, 2017

@rabisg I apologize, I've had other projects and my day job take priority here. I'd be more than happy to take a PR on this.

@Yamakaky
Copy link

Yamakaky commented Feb 2, 2017

Seems to be a problem with the .gitignore handling. With an empty crate generated with cargo new, it says there isn't "any file matching the criteria". If I remove the .gitignore, it outputs the line counts as expected.

@rabisg
Copy link

rabisg commented Feb 13, 2017

Just a heads up. My PR got merged in nathankleyn/gitignore.rs#12 and v1.0.6 was released. Since I cannot devote time to this right now if someone wants to update this repo I'll be happy to help

@Aeledfyr
Copy link

@kbknapp All you should need to do right now to fix this would be to either update the Cargo.toml to have 1.0.6 as the min version for gitignore, or just to remove the Cargo.lock and rebuild. Then you would only need to release a new version to crates.io, and it would work. Even just cloning the repo works right now, just not the version on crates.io.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants