Hi Peff, On Fri, 3 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:03:56AM +0100, Johannes Schindelin wrote: > > > These patches are an attempt to make Git's startup sequence a bit less > > surprising. > > > > The idea here is to discover the .git/ directory gently (i.e. without > > changing the current working directory, or global variables), and to > > use it to read the .git/config file early, before we actually called > > setup_git_directory() (if we ever do that). > > Thanks for working on this. I think it's a huge improvement over the > status quo, and over the earlier attempt. I don't see anything hugely > wrong with this series, though I did note one bug, along with some minor > refinements. Thank you very much for your review. You did point out a couple of things I overlooked, and while it was a pain in the back to go from v1 to v2 (i.e. avoiding code duplication, which immediately put the changed code to a huge test by having the very central setup_git_directory() use it), I really believe that we are better off because the patch series pays off more technical debt now than it introduces. > > My dirty little secret is that I actually need this for something else > > entirely. I need to patch an internal version of Git to gather > > statistics, and to that end I need to read the config before and after > > running every Git command. Hence the need for a gentle, and correct > > early config. > > We do something similar at GitHub, but it falls into two categories: > > - stat-gathering that's on all the time, so doesn't need to look at > config (I'm not sure in your case if you want to trigger the > gathering with config, or if config is just one of the things you > are gathering). > > - logging that is turned on selectively for some repos, but which > doesn't have to be looked up until we know we are in a repo You probably guessed what I need to do, anyway: for our GVFS usage, we need some telemetry (i.e. usage statistics), and I basically want to run a hook whenever any Git command is called, but only on GVFS-enabled repositories. So it is somewhat related, but slightly different from your usage. > I looked into making something upstream-able, and my approach was to > allow GIT_TRACE_* variables to be specified in the config. But of course > that ran into the early-config problem (and I really wanted repo-level > config there, because I'd like to be able to turn on tracing for just a > single problematic repo). > > So not really something you need to work on, but maybe food for thought > as you work on your internal project. Right, GIT_TRACE_* settings in the config should be doable now. Ciao, Dscho
