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

Support p4ignore #53

Open
unional opened this issue Dec 23, 2015 · 5 comments
Open

Support p4ignore #53

unional opened this issue Dec 23, 2015 · 5 comments

Comments

@unional
Copy link
Collaborator

unional commented Dec 23, 2015

https://www.perforce.com/blog/120214/new-20121-p4ignore

Currently atom-perforce will try to add the file every time I save the file.

@mattsawyer77
Copy link
Owner

@unional I wasn't sure how to contact you. But I've made you a collaborator on this project, in case you want to push directly to the repo. side note: I am not using Atom right now (and I'm primarily using git -- though still inside perforce), so my activity on this project may be a bit slow.

@mattsawyer77
Copy link
Owner

sorry just now thought about the actual topic. why don't you want to check in your .p4ignore file?

@unional
Copy link
Collaborator Author

unional commented Jan 6, 2016

:)

Sorry I didn't make it clear in my original message. What I meant is changing the files specified in .p4ignore.

e.g., I want to ignore *.json, and when I add/edit/save abc.json, atom-typescript tries to add/edit the file, which p4 will complain.

@mattsawyer77
Copy link
Owner

OK, that makes sense.

@PhiLhoSoft
Copy link

A good support of .p4ignore should also comply to the Exclude VCS Ignored Paths setting, ie. if checked, they should disappear from the tree-view and from the searches.

Currently, I use the atom-tree-ignore package for that, duplicating part of the .p4ignore content, and it doesn't support hiding from searches.

The above package uses the ignore NPM library to support .gitignore-like rules. Not sure exactly how .p4ignore rules differ from these, for practical purposes (ie. if they are a subset of the former, that's OK to use).

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

No branches or pull requests

3 participants