Ignore .DS_Store in /home about homeshick

[andsens]

Good idea. Though I don't like hardcoding stuff like that.
How about reading the things link should ignore from the .gitignore file?
Incidentally we could use git ls-files instead of find for that I believe.

[leoj3n]

From a .gitignore in /home or one dir up, in the castle?

On Sun, Dec 15, 2013 at 4:26 AM, Anders Ingemann
[email protected]:

Good idea. Though I don't like hardcoding stuff like that.
How about reading the things link should ignore from the .gitignore file?
Incidentally we could use git ls-files instead of find for that I believe.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/73#issuecomment-30601767
.

[andsens]

Well git ls-files would take all those into consideration, even .gitignore-global, which is where I would ignore stuff like .DS_Store.

[leoj3n]

I can't think of any potential issues; has my vote. 👍

[andsens]

Since git 1.8.2 there is git check-ignore, given a path it returns whether the file is ignored.
Using that would avoid having to rewrite the entire linking function (ls-files only lists files, not folders like find). check-ignore exits with 0 if a file is ignored and 1 if it isn't. This also works with force added files (i.e. it returns 1).

I think it would be fair to require git 1.8.2 for this feature to be working and simply fall back to not checking for ignored files when git < 1.8.2.

[leoj3n]

Sounds good! Only thing I can think to add for you to look at (not sure if it really helps) is this prezto alias which lists ignored files inside a repo:

https://github.com/sorin-ionescu/prezto/blob/master/modules/git/alias.zsh#L75

I'm sure check-ignore is fast, and falling back to the default behavior for git versions < 1.8.2 should be harmless as long as it's well documented.

[andsens]

Only thing I can think to add for you to look at (not sure if it really helps) is this prezto alias which lists ignored files inside a repo
alias gdi='git status --porcelain --short --ignored | sed -n "s/^!! //p"'

Hm interesting, especially because it uses --porcelain and seems like a rather stable command.
This is certainly an option if we want backwards compatibility.

However, for stabilities sake I think I'll refrain from implementing that, checking whether an exit code is 0 or 1 has a much lower chance of going wrong. I'll leave the backwards compatible part to someone who really needs it and creates a PR.

[andsens]

I'm merging this into #95 since solving it would also solve this issue.