Running cloc from inside a git repo may fail

[olemd]

Running cloc from inside a new-ish directory inside a git repo may fail with the somewhat confusing message

fatal: current working directory is untracked
Failed to create tarfile of files from git. at /usr/bin/cloc line 5201.

In my case this was caused by the following:

cd ~/src/git-repo/new_subdir
cloc --json --report=my-report.json --git abc234 ~/src/git-repo

This appears to be caused by cloc running git-archive from inside new_subdir with a git hash that refers to a source tree that doesn't contain new_subdir.

A working workaround is

cd ~/src/git-repo
cloc --json --report=my-report.json --git abc234 ~/src/git-repo

Setting the current working directory to the top of the git-repo before running git-archive in cloc would appear to be a fix for this.

Strictly speaking this is not a cloc bug, it might be considered a git-archive bug, but the result is nevertheless rather confusing.

[AlDanial]

That's an interesting edge case. At first I thought changing directories as you mentioned would be a simple fix but that introduces the new complications of identifying the top of the repo and then trying to figure out if it is necessary to prepend that directory fragment on the input directory. Then there's the diff case where one input may be a directory and the other a tar file.

I'll keep this open for a while in case a brilliant solution hits me but my gut feel at the moment is to not try to fix this in cloc.

[olemd]

Absolutely an edge case. I'm solving it for me with something like

git_top=$(git rev-parse --show-toplevel)
cloc_work_dir=${git_top}
pushd $git_top
cloc --git ${commit_id} ${cloc_work_dir}
popd

A more general solution should probably be to handle cloc_work_dir differently, in case the user wants to run cloc on a subtree and not the whole repo (which would break for git hashes that don't have that subdirectory).

Also, git rev-parse --show-toplevel "relatively new" - I think it was introduced around 1.8 or so?