Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > 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. The single most common reason why a bare repository is bare is because nobody regularly logs in to the machine that hosts it and goes there to access its contents. 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. Once we add ways to expose information kept in reflog of a bare repository more effectively and conveniently, the argument could become "should be enabled now it would be very useful to have one". I mentioned a possible option to show reflog entry annotations in gitweb. That was an example of such an addition of "a way to expose". It also is plausible to teach git-daemon a remote "log" request; similar to "git fetch" running "upload-pack" on the other end in the bare repository, a "git log --remote" command may run "upload-log" on the other end and this service may allow passing the "-g" option when it does so. That would be another addition of "a way to expose". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html