git ls-tree output of working directory?

This is similar to @mikel's answer, but uses git stash create and ls-tree, as requested by the OP. Also avoids using git reset, which is more likely to break things for the inexperienced user.

This however only works for tracked files.

git ls-tree `git diff --quiet && echo HEAD || git stash create ls-tree`

This will leave a dangling commit, which will should eventually be removed by git gc. (Actually two dangling commits.) Of course you could search for dangling commits containing ls-tree, but I haven't found a simple way to do so (at least not without quite a bit of sed and grep magic - suggestions welcome ).

Explanation

git ls-tree needs a hash. If the tree is clean (git diff --quiet returns 0) one can use HEAD. If it isn't, git stash create will create a commit and return it's hash.

Untracked

Unfortunately git stash create does not support -a/-u or other flags. Thus it's not possible to show the hashes of untracked files. Getting their information is a bit more complicated:

git stash -a
git ls-tree stash
git ls-tree stash^3
git stash pop

This will first show tracked files (git ls-tree stash) and then untracked files (git ls-tree stash^3). torek provides a good explanation why stash^3 is needed.


Tried to find something which is not touching the git repo.

This one is not git only and depends on linux like 'grep'

#from root of repo dir
git ls-tree -r HEAD 
#other dirs
git ls-tree -r HEAD | grep <relative_path_to_repo_root>/
# eg
git ls-tree -r HEAD | grep src/

Also found following (git only) working in subdirectories of repo root

git ls-tree -r --full-name HEAD

However man page (man git-ls-tree) is irritating git logic

   --full-name
       Instead of showing the path names relative to the current working directory, show the full path names.

   --full-tree
       Do not limit the listing to the current working directory. Implies --full-name.

git ls-tree only works with git refs, e.g. ls-tree HEAD or ls-tree 1.9.1

Try git ls-files. You probably want the -s and/or -m flags.

As you point out, git ls-files -s will list the files in the index (i.e. files that have been staged).

In theory, you could mess with the index, run git ls-files -s, then try restore it, e.g.

git commit
git add .
git ls-files -s
git reset .
git reset --soft HEAD^

Seems right, and worked in a simple test, but could eat all your files.

Tags:

Git

Recent Posts