I am looking for a way to have output in the same manner as ls-tree
, but of my working directory. Whenever I run git ls-tree .
it says fatal: Not a valid object name .
the behaviour is similar to that of "/bin/ls" in that the <path> is taken as relative to the current working directory. E.g. when you are in a directory sub that has a directory dir, you can run git ls-tree -r HEAD dir to list the contents of the tree (that is sub/dir in HEAD ).
Another term demystified. Th Working Tree in Git is a directory (and its files and subdirectories) on your file system that is associated with a repository. It's full of the files you edit, where you add new files, and from which you remove unneeded files.
git directory is a configuration file for git. Use the terminal to display the . git directory with the command ls -a . The ls command lists the current directory contents and by default will not show hidden files.
The git log command is a useful command that allows you to look at Git commits history. However, this text-based log may not be preferred by most users, since the output can be very difficult and complex to visualize and interpret. A more visually appealing way to present this log is in the form of a Git tree.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With