20

Let's say I have this worktree that has already been tracked by git.

.
├── parent
│   ├── child1
│   |    └── file1.txt
│   ├── child2
│   |    ├── file2.txt
│   |    └── grandchild
│   |         └── file3.txt
│   ├── somefile.txt
│   └── anotherfile.txt
|

I want to mark every tracked files inside parentso that any changes made to them woudln't be tracked by git anymore, which in the end would include somefile.txt, anotherfile.txt, file1.txt, file2.txt, file3.txt.

.gitignore only works on untracked files so I'm using --skip-worktree.

I tried:

1.

git update-index --skip-worktree parent/

Gave me Ignoring path parent/ but when I check git ls-files -v, it still shows me that the files I want to skip are still tracked.

2.

git update-index --skip-worktree parent/*

It gave me fatal: Unable to mark file parent/child1 so it cannot mark a directory and anything it contains.

How can I do this without manually add every file I have inside parent?

kucinghitam
  • 414
  • 3
  • 12

1 Answers1

20

Similarly to assume-unchanged, you need to apply this command to all files within a folder:

find . -maxdepth 1 -type d \( ! -name . \) -exec bash -c "cd '{}' && pwd && git ls-files -z ${pwd} | xargs -0 git update-index --skip-worktree" \;

(there is no "recursive" option to git update-index)

EDITED:

Don't forget to cd into the directory that you want to skip first, then run the above commands.

And, if you want to undo it, just do the opposites with this:

find . -maxdepth 1 -type d \( ! -name . \) -exec bash -c "cd '{}' && pwd && git ls-files -z ${pwd} | xargs -0 git update-index --no-skip-worktree" \;
mochadwi
  • 1,190
  • 9
  • 32
  • 87
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 2
    Thanks, your command worked. Although I also tried `git ls-files -z parent/ | xargs -0 git update-index --skip-worktree` based from that question, it also worked but with fewer command which is nice. Is there any difference or drawback using that? Sorry I'm not that proficient when it comes to terminal. – kucinghitam Apr 26 '19 at 06:54
  • 1
    @kucinghitam The command line i mention will scale better if you have a *massive* number of files. If not, your shorter version will work too. – VonC Apr 26 '19 at 07:11