Running git on 'next', you can trigger a BUG: $ cd /some/repo $ git pack-objects --all --stdout </dev/null >/tmp/foo.pack $ cd /not-a-git-repo $ git index-pack --stdin </tmp/foo.pack fatal: BUG: setup_git_env called without repository This obviously comes from my b1ef400eec (setup_git_env: avoid blind fall-back to ".git", 2016-10-20). What's going on is that index-pack uses RUN_SETUP_GENTLY, but never actually handles the out-of-repo case. When we use the internal git_dir to make "objects/pack/pack-xxx.pack", it barfs. In older versions of git will just blindly write into ".git/objects/pack", even though there's no repository there. So I think complaining to the user is the right thing to do here. I started to write a patch to have index-pack notice when it needs a repo and doesn't have one, but the logic is actually a bit unclear. Do we need to complain early _just_ when --stdin is specified, or does that miss somes cases? Likewise, are there cases where --stdin can operate without a repo? I couldn't think of any. I'm actually wondering if the way it calls die() in 'next' is a pretty reasonable way for things to work in general. It happens when we lazily try to ask for the repository directory. So we don't have to replicate logic to say "are we going to need a repo"; at the moment we need it, we notice we don't have it and die. The only problem is that it says "BUG" and not "this operation must be run in a git repository". That strategy _might_ be a problem for some programs, which would want to notice the issue early before doing work. But it seems like a reasonable outcome for index-pack. Thoughts? -Peff