Re: Contributor Summit planning

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Mar 05 2018, Jonathan Nieder jotted:

> Lars Schneider wrote:
>> - error reporting: Git is distributed and therefore lots of errors are only
>>   reported locally. That makes it hard for administrators in larger
>>   companies to see trouble. Would it make sense to add a config option that
>>   would push recent errors along with "git push" to the server?
>
> I'm interested in instrumentation but worried about the privacy
> ramifications of this particular proposal.  I'd be happy to see some
> built-in instrumentation hooks (or even a standard instrumentation
> approach, if the mailing list comes up with a good one that respects
> privacy).

I have this use-case as well, and figured a good approach would be:q

 1. Add corresponding config variables for GIT_TRACE_* so you could
    config them in /etc/gitconfig (or elsewhere). Similar to
    e.g. user.name & GIT_AUTHOR_NAME

 2. Add some new trace like e.g. GIT_TRACE_COMMANDS, make it take a
    format string in GIT_TRACE_COMMANDS_FORMAT (or usually via
    config). Thus setting GIT_TRACE_COMMANDS to a file would e.g. spew
    your current repo path, subcommand, or even the absolute command
    line to the file.

 3. Have some cronjob or other monitoring thingy pick up the file &
    submit to central logging.

Of course you could overdo the format specifiers in #2 and e.g. send the
full commands along, but it seems to me that it would be sufficient for
privacy concerns to document that caveat with some examples.

After all, for this use-case we're talking about us somehow guarding
against a sysadmin who can just install a /etc/profile.d/git_wrapper
anyway that'll log everything you do with git, or even provide a custom
git binary, so it's always going to be left to their best judgement.