Samuel Maftoul, HOME is not set to root's HOME by Chef, it is not set at all. shell_out does not start a login shell (CHEF-2288), it just runs a command.
This bug is in git, not Chef, but we may have to deal with git's bug. Other tools have run into the same issue, like Redmine.
4698c8feb in git resolves this bug and explains the situation well. Similarly, shell_out shouldn't make assumptions about what you might want your variables to be set to and cannot set those variables in such a way you can't change them. Git tag reports that commit was included in Git 18.104.22.168. The bug was introduced in 96b9e0e31 and released first in Git 22.214.171.124. I would suspect some distributions aren't going to get an update.
The solution presented to use Etc won't work. As previously noted, it isn't portable, and I wonder if there are cases where it would report something that we don't want, and then need a way to override it. Ignoring that case, I imagine the solution would be to implement a feature in mixlib-shellout to provide a login shell, and then have the git resource use that option when --user is set.
Benedikt Böhm I'm not completely convinced we want to set environment variables by default anytime a user is passed, but I guess it's okay. 5a4cc1122f should not set HOME or USER if they've been passed to the environment hash. user can be a name or a uid, so that should be handled. Since uid is right there, it's probably easiest to call getpwuid against the uid rather than add logic to determine if user is a name or uid. Finally, there should be unit tests.