1

I am workin on a git repository. I have a working copy, with huge file list.

My .gitignore looks like

roo/output*  # ignore set of folders
*.pyc           # ignore a filetype
root/a_folder   # ignore a folder
root/filemame*.txt # ignore a set of files
root/**/.bin # ignore an extension within a folder

Now I would like to create a new working copy. In order for it to work, I also need the files which are gitignored in the original wc.

I have tried some of the answers here:

Git command to show which specific files are ignored by .gitignore

git check-ignore * # return only folders for me

git status --ignored # takes forever to run
git ls-files --others -i --exclude-standard # returns empty for me

I would need to get this list with the original path names, so that I can create a zip file keeping the folder structure so that I can unzip it seamlessly in the new working copy.

00__00__00
  • 4,834
  • 9
  • 41
  • 89
  • 1
    That `ls-files` should not be returning empty, it should be listing all untracked files that match an ignore pattern. That's what it's documented to do and what it does for me. – jthill Jul 24 '18 at 14:14

3 Answers3

1

Well, we can look at how to make git check-ignore work better, but this seems like a bit of over-engineering. If you only need to do it once, just figure out what to include form the patterns you know are in the ignore file. (I'm ignoring this directory, so I'll zip up this directory. etc.) If you need to do this routinely, you might want to revisit how you're using ignore rules.

Anyway, the check-ignore command may output files and/or directories, with two caveats:

First, you need to tell it if you want to search subdirectories. If you just say git check-ignore * then it will only search the current directory. Instead you might want

git check-ignore * **/*

But even then, the second problem comes up when you exclude a directory a/, and that directory contains another directory a/b/. There's bad news and worse news.

The bad news is, it doesn't search inside a/b/ even with the **/* pattern; once it sees that a/b/ is excluded, it just lists that and moves on.

The worse news is, if any non-excluded paths exist inside a/b/ (e.g. because they were added before the path was ignored, or because they were added with -f), then a/b/ is not listed, and it still doesn't search under a/b/ to find if more specific paths really are excluded. This seems to me like a bug. As a partial work-around, you can say

git check-ignore --no-index **/* *

and it will list the directory, but still won't search inside the directory - which means you have some implicit false positives (since some things in that directory are not ignored files).

So... if you either (a) know that the index contain no entries for files at paths that would otherwise be ignored, or (b) can get by with possibly picking up some non-ignored files by using --no-index, then you could use the `check-ignore output. In cases where you see a directory, you'd just include that entire directory (and its contents, recursively) in the ZIP.

In the case where this would copy a file that isn't really ignored, I guess doing something like

git checkout -- a/b

after extracting your ZIP should address that. (You can always use git status after extracting the ZIP to verify if there are any non-ignored changes you'd want to undo.)

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
  • I like the answer. In this context is indeed much better to risk false positives than loosing some files – 00__00__00 Jul 30 '18 at 10:05
  • Could you please add a simple way to feed this list generated by git into a zip/tar file in linux? Then it completely answers the question and I can accept it – 00__00__00 Jul 30 '18 at 10:06
1

Here's what works for me. At first, to check, I list all ignored files, without the contents of ignored directories (so just the directories themselves):

$ git ls-files -o -i --directory --exclude-standard
TODO
some/ignored/dir/

Then I pass this list to zip in a one-liner to save everything to ignored-files.zip:

$ zip ignored-files.zip -r $(git ls-files -o -i --directory --exclude-standard)
Ronino
  • 131
  • 2
1

Another (somewhat overlooked) approach, is using git clean in dry-run mode:

git clean -dxn

recurses over all sub-directories, spitting out the name of each file that is not on git, either new or ignored (the -x flag makes sure ignored files are included in the output).

In order to clean the prefix Would remove that shows on each line of git-clean 's output and sending this to zip, one would type:

git clean -dxn | sed 's/^Would remove \(.*\)/\1/g' | zip -@ backup-file.zip
KishKash
  • 161
  • 4