Yarn runs git commands in the background, so it looks like git pull is returning a non-zero exit code, which bubbles back up through yarn. It's not really explicitly stated anywhere in the Yarn docs that I know of, but your git system needs to be set up correctly (i.e. if running a git command on the command line doesn't work, then neither will Yarn).

Some other applications have this same issue https://stackoverflow.com/questions/11656761/git-please-tell-me-who-you-are-error which I think git requires because the pull command could perform an automerge in which case it would want to make a commit, which would need your user info.

Is there a reason you can't configure git with the name and email? Perhaps there is a way for Yarn to do the same thing without the git pull command which could circumvent this problem.

that's why I mentioned in issue summary:

no global git user is configured

that's exactly the reason of the issue.

but I find yarn using my git profile as abuse of my profile, yarn shall not do anything with my profile.
I do not configure global git profile, as I do have multiple git users (even for same git server), thus I want to be explicit with which user I'm commiting, so I have configure the user per-repo.
Creating my own dummy git-user is not an option, as it leads to situation when I will, accidentally, commit changes with that dummy user to real repo one day.

Also, be aware that if I rm -rf ~/.cache/yarn, everything is installed, even if it is still using git without global user under the hood

That makes sense. Thanks for the additional info. Do you have a dependency that is a github url? I'm trying to trace back why it would be using git pull in the cache in the first place (I suspect the first install does a git clone which doesn't require a profile).

Setting a "dummy user" for the project seems questionable. We would have to start detecting if a user exists first, then set one, then clear it again when done. I think it might be easier to use git fetch && git reset --hard together instead of git pull which then shouldn't throw that git error.

yes, I do have git-based package, as it's visible in my first post:

git://github.com/adobe-fonts/source-sans-pro

in concrete, it's

"source-sans-pro": "git://github.com/adobe-fonts/source-sans-pro.git#2.020R-ro/1.075R-it",

worst case scenario, it could always clone the repo with given version:

git clone -b $branch_or_tag [email protected]:org-name/repo-name.git

Git should only need a user name/... when you want to commit. The "read only" operations usually don't need git info configured. But git pull might automatically do a merge, which would need a user name/..., but I don't think yarn would ever want to trigger a merge when updating its cache. Yarn shouldn't be creating new commits in the repositories it tries to clone.

So fetch + reset seems like the way to go. And if we don't need the checked out files, using a bare repository would further simplify the situation and save disk space an IO activity.

But it turns out yarn already did once use bare repositories and fetch instead of pull, it was changed in #514. It's not clear to me why/how exactly that change solved the bug it apparently did solve.

"good" there are some tests for that bug...

We have hit this twice over the last few months on our CI builds. Is there any progress or suggested workarounds? The current workaround of manually clearing the cache isn't very practical.

also ran into this issue today.