On Sun, Jun 10, 2018 at 12:44:25AM +0200, Johannes Sixt wrote: > > I agree with Peff: this is something you as a user need to be aware of, > > and need to make sure you configure your Git just like you want. As long > > as this is a purely opt-in feature, it is useful and helpful. > > The problem with this feature is not so much that it enables someone to do > bad things, but that it is specifically targeted at recording *how users use > Git*. I think one issue here is that we are not looking at concrete patches. So for instance, I've seen a claim that Git should never have a way to turn on tracing all the time. But at GitHub we have found it useful to have a config option to log the sha1 of every object that is dropped by git-prune or by "repack -ad". It's helped both as a developer (tracking down races or bugs in our code) and as an administrator (figuring out where a corruption was introduced). It needs to be on all the time to be useful, since the point is to have an audit trail to look at _after_ a bad thing happens. That's something we do completely on the server side; I don't think there are any privacy or "spying" issues there. And I don't think it's a huge maintenance burden. Inside the existing code, it's literally a one-line "log this" (the log code itself is a hundred or so lines in its own file). Now most users probably don't care that much about this use case. And I'm OK to apply it as a custom patch. But doesn't it seem like that's something other people hosting Git repos might want? Or that the concept might extend to other loggable items that _are_ interesting on the client side? That's why I think it is worth taking this step-by-step. Let's log more things. Let's make enabling tracing more flexible. Those are hopefully uncontentious and universally useful. If you want to draw the line on "spying", then I think the right place to draw it is when somebody wants to ship code to actually move those logs out of the user's control. -Peff
