Re: thoughts on setting core.logAllRefUpdates default true for bare repos

Junio C Hamano [off-list ref] writes:

Matthieu Moy [off-list ref] writes:

quoted

I can't think of any, and I just tried launching two

while true; do git pull; date > foo.txt ; git add .; git commit -m "xxx"; git push; done

in parallel, with two different users pushing to a --bare --shared
repository, and it did work well. But I may very well have missed
something.

(and actually, if it causes problem, it's an argument in favor of
defaulting to false when core.shared is true, not when core.bare).

Unless I missed something, I think core.logAllRefUpdates should be
enabled for bare repos.

Your experiment justifies "could be enabled safely" and saying "should be"
based on that is a bit too strong and also premature.

Right, there were no cause/effect relationship between the first part
and the "should".

As reflog is a local thing, and not exposed to outside world,
enabling it alone would not help a lot to people who do not have
such a direct access to the bare repository, which by definition is
the majority because the reason why the repository is bare to begin
with.

For sure, it's the majority. But it's not 100% cases either.

And in most cases, even if the user doesn't have access to the repo,
there exists a sysadmin somewhere who has. And the day a user will
send a mail "hey, I've messed up everything, I did a push -f and what
happened?", this sysadmin will appreciate to have a log somewhere.

And another use-case for the reflog is to find know reliable where a
piece of code is comming from. "git blame" tells you who the commiter
said he was, while the reflog says reliably who the push-er was.

So, clearly, the reflog on a bare repo is not usefull for daily use
like it is for non-bare repos (where, really, it's a killer
feature ;-) ). But it doesn't seem useless either, and it doesn't cost
much, so ...

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/