Show HN: Apply .gitignore files to Time Machine backups

#1

Post by baleb » Mon, May 27, 2019, 9:54 AM UTC

Show HN: Apply .gitignore files to Time Machine backups
github.com

Re: Show HN: Apply .gitignore files to Time Machine backups

#2

Post by eps » Mon, May 27, 2019, 4:43 PM UTC

This is dangerous. This will suppress the backup of files that were added to the repo with a manual override, against .gitignore rules.

Re: Show HN: Apply .gitignore files to Time Machine backups

#3

Post by baleb » Mon, May 27, 2019, 5:30 PM UTC

eps wrote: post #2

This is dangerous. This will suppress the backup of files that were added to the repo with a manual override, against .gitignore rules.

I don't think that's true.

If I understand you correctly, you mean files that are matched by rules in a .gitignore but staged using the -f option and then committed. The command this script uses to obtain the list of files to exclude is:

    git ls-files --directory --exclude-standard --ignored --others

A file staged and committed as described above is not listed using that command, and therefore not excluded from backups.

Re: Show HN: Apply .gitignore files to Time Machine backups

#4

Post by eps » Mon, May 27, 2019, 9:05 PM UTC

baleb wrote: post #3

eps wrote: post #2

This is dangerous. This will suppress the backup of files that were added to the repo with a manual override, against .gitignore rules.

I don't think that's true. If I understand you correctly, you mean files that are matched by rules in a .gitignore but staged using the -f option and then committed. The command this script uses to obtain the list of files to exclude is: git ls-files --directory --exclude-standard --ignored --others A file staged and committed as described above is not listed using that command, and therefore not excluded from backup…

I couldn't get the .py source load on mobile, so I went by the post title. If it goes through ls-files, then it should be fine.

Though it's not really just .gitignore anymore. Plus it depends on git and its performance... I'm just thinking of really large repos. This approach would basically mean that the tree is scanned twice.