Enhancement Request : tar options for git hash cloc and diff

[iMortalitySucks]

When running cloc against a git hash, it uses tar to package up the files for comparison. However, on Windows, if you are running tar on a different drive than the source code and you are using full paths, it causes errors "Cannot connect to X: resolve failed". This is a known issue with tar where if there is a ':' in the path, it thinks it is connecting to another computer for some reason. To resolve this tar has a --force-local option that will force it to assume its a local path instead of a network one.

Can you/someone add this as a command line option to cloc to pass through to tar please? Inversely, if the --extract-with option also applied to archiving, the user could choose to use gzip, 7zip or something other than just tar.

Looks like the code is in sub replace_git_hash_with_tarfile around line 4864.

[AlDanial]

Here's a thought: cloc can easily examine the file path and determine if the colon is part of a letter drive or part of the file/directory's name. If the current directory and the file path share the same leading letter and colon, it will add --force-local. There is also the --sdir option which tells it the location of the scratch work area it should use (though n honesty I don't look to see if I implemented that for the git operations). In theory you could tell to cloc to use a path for tar work in the same location as the source code, then it could use --force-local.

In any event, I will be tied up for the next 2-3 weeks so it will be a bit before I'm able to study this more closely.

[AlDanial]

Been a while but I haven't forgotten this issue. Sadly it is more complex than I first thought because cloc doesn't directly invoke the tar command while doing git diffs. Instead, tar is called via the git archive command (called in the same-named Perl subroutine within cloc). git archive does not have provisions for passing arbitrary switches, namely --force-local, to the underlying tar command.

Two work-arounds come to mind but I'm not keen on implementing either one. 1) separate the actions of git archive into separate steps, one of which is the tar command itself, or 2) go back to using zip as the archive format in Windows. Both introduce new headaches. I'll consider a PR though.