4

I have a git related question (git pull fails on my webserver) and to further describe my problem I thought it could be a good idea to offer also my .git directory so that git geeks could look inside and figure out what could be the problem.

Is it a good idea to make public a .git folder OR what to look out for when doing so OR what kind of dump message from git should be offered for debugging git errors?

asynts
  • 2,213
  • 2
  • 21
  • 35
obeliksz
  • 468
  • 9
  • 24

3 Answers3

3

Security

Making public the .git directory is just like make public your repo. If there's no sensitive information in your repo (keys written to hooks or remote-paths what contains secrets, files with plain-text passwords) then it is ok to share.

Debugging

answer taken from @kenorb at How can I debug git/git-shell related problems?

Git has a fairly complete set of traces embedded which you can use to debug your git problems.

To turn them on, you can define the following variables:

  • GIT_TRACE for general traces,
  • GIT_TRACE_PACK_ACCESS for tracing of packfile access,
  • GIT_TRACE_PACKET for packet-level tracing for network operations,
  • GIT_TRACE_PERFORMANCE for logging the performance data,
  • GIT_TRACE_SETUP for information about discovering the repository and environment it’s interacting with,
  • GIT_MERGE_VERBOSITY for debugging recursive merge strategy (values: 0-5),
  • GIT_CURL_VERBOSE for logging all curl messages (equivalent to curl -v),
  • GIT_TRACE_SHALLOW for debugging fetching/cloning of shallow repositories.

Possible values can include:

  • true, 1 or 2 to write to stderr,
  • an absolute path starting with / to trace output to the specified file.

For more details, see: Git Internals - Environment Variables

SSH

For SSH issues, try the following commands:

echo 'ssh -vvv $*' > ssh && chmod +x ssh
GIT_SSH="$PWD/ssh" git pull origin master

or use ssh to validate your credentials, e.g.

ssh -vvvT git@github.com

or over HTTPS port:

ssh -vvvT -p 443 git@ssh.github.com

Note: Reduce number of -v to reduce the verbosity level.

Examples

$ GIT_TRACE=1 git status
20:11:39.565701 git.c:350               trace: built-in: git 'status'

$ GIT_TRACE_PERFORMANCE=$PWD/gc.log git gc
Counting objects: 143760, done.
...
$ head gc.log 
20:12:37.214410 trace.c:420             performance: 0.090286000 s: git command: 'git' 'pack-refs' '--all' '--prune'
20:12:37.378101 trace.c:420             performance: 0.156971000 s: git command: 'git' 'reflog' 'expire' '--all'
...

$ GIT_TRACE_PACKET=true git pull origin master
20:16:53.062183 pkt-line.c:80           packet:        fetch< 93eb028c6b2f8b1d694d1173a4ddf32b48e371ce HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/2:2.6.5~update-ref-initial-update-1494-g76b680d
...
obeliksz
  • 468
  • 9
  • 24
2

if you never had sensitive information in your repository, then yes, otherwise no. (assuming you never did exotic things, like writing keys into a hook, or having a remote-path that contains a secret).

If you never modified your .git folder directly, then will only contain the secrets, that were in your repo all along.

Note: you ssl-certificates are not stored in the .git folder; those are handled by your system.

wotanii
  • 2,470
  • 20
  • 38
  • if I was writing keys into a hook where to check it in .git? what kind of secrets could have been in my repo all along? Like plain text passwords in code comments or what are what to think of? Is the .git folder the thing to offer for debugging or rather some git reports, generated with a git command? – obeliksz Sep 13 '18 at 19:03
1

There isn't problem to make the .git public. Sharing this file is in fact sharing your repository and it may be a good idea for an expert give you a hand.

The only personal information that could be leaked would be your email address. Everything related to SSH keys or passwords goes separately.

Of course, all those files that you have included in the different versions will be published, as well as the messages of the commits. It's the only thing that should be watched.

bglezseoane
  • 146
  • 1
  • 6