{"thread":{"id":"21482","subject":"thoughts on setting core.logAllRefUpdates default true for bare repos","startedAt":"2009-11-04T12:55:53Z","lastAt":"2009-11-05T01:28:08Z","messageCount":11,"participants":["Sitaram Chamarty","Johannes Schindelin","demerphq","Matthieu Moy","Junio C Hamano","Nicolas Sebrecht","Sverre Rabbelier"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"126761","messageId":"slrnhf2uep.7d3.sitaramc@sitaramc.homelinux.net","threadId":"21482","inReplyTo":null,"subject":"thoughts on setting core.logAllRefUpdates default true for bare repos","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-11-04T12:55:53Z","receivedAt":"2009-11-04T12:55:53Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"It seems to me an accidental push -f would cause some\ntrouble on a bare repo, and would usually require a bit of\ngrubbing around among the unreachable commits looking for\nthe right one.\n\nWhat would be the downsides (other than some objects hanging\naround far longer, i.e., space issues) of setting the config\nvariable core.logAllRefUpdates to be default true on bare\nrepos.\n"},{"id":"126762","messageId":"alpine.DEB.1.00.0911041422170.2788@felix-maschine","threadId":"21482","inReplyTo":"slrnhf2uep.7d3.sitaramc@sitaramc.homelinux.net","subject":"Re: thoughts on setting core.logAllRefUpdates default true for bare repos","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-04T13:25:33Z","receivedAt":"2009-11-04T13:25:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 4 Nov 2009, Sitaram Chamarty wrote:\n\n> It seems to me an accidental push -f would cause some trouble on a bare \n> repo, and would usually require a bit of grubbing around among the \n> unreachable commits looking for the right one.\n\nIn one usage of mine, we have set said config value for exactly that \nreason.\n\n> What would be the downsides (other than some objects hanging\n> around far longer, i.e., space issues) of setting the config\n> variable core.logAllRefUpdates to be default true on bare\n> repos.\n\nI did not have time yet to investigate, but it seems that there are \nproblems with the permissions of shared bare repositories when activating \nthe reflogs.\n\nWith gitweb on a public site, there might be a problem when you pushed \nsome blob containing trade secrets accidentally, and try to scrub the \nrepository using \"git gc\" after a forced push.\n\nThat are the only downsides I can think of.\n\nCiao,\nDscho\n"},{"id":"126773","messageId":"2e24e5b90911040841l7741787et48fabb8c8066e946@mail.gmail.com","threadId":"21482","inReplyTo":"alpine.DEB.1.00.0911041422170.2788@felix-maschine","subject":"Re: thoughts on setting core.logAllRefUpdates default true for bare repos","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-11-04T16:41:11Z","receivedAt":"2009-11-04T16:41:11Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"Hi Johannes,\n\nOn Wed, Nov 4, 2009 at 6:55 PM, Johannes Schindelin\n wrote:\n\n> I did not have time yet to investigate, but it seems that there are\n> problems with the permissions of shared bare repositories when activating\n> the reflogs.\n\nInteresting; I will try and investigate if I can find something.\n\n> With gitweb on a public site, there might be a problem when you pushed\n> some blob containing trade secrets accidentally, and try to scrub the\n> repository using \"git gc\" after a forced push.\n\nAgreed. This config variable is biased to *keep* data if set to true,\nand (default) false value is biased not to keep that same data, so\nthat will always be a conflict.\n\nBut if you are able to do \"gc\" manually on any repo you can also do\n\"reflog expire\" before \"gc\" can you not? Please correct me if I'm\nwrong.\n\nRegards,\n\nSitaram\n"},{"id":"126776","messageId":"9b18b3110911040915q1dfa5a4bk18087d93a00f4cf5@mail.gmail.com","threadId":"21482","inReplyTo":"2e24e5b90911040841l7741787et48fabb8c8066e946@mail.gmail.com","subject":"Re: thoughts on setting core.logAllRefUpdates default true for bare repos","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-11-04T17:15:17Z","receivedAt":"2009-11-04T17:15:17Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/11/4 Sitaram Chamarty :\n> Hi Johannes,\n>\n> On Wed, Nov 4, 2009 at 6:55 PM, Johannes Schindelin\n> wrote:\n>\n>> I did not have time yet to investigate, but it seems that there are\n>> problems with the permissions of shared bare repositories when activating\n>> the reflogs.\n>\n> Interesting; I will try and investigate if I can find something.\n\nAssuming you mean via ssh access then if there is we haven't noticed\nthe problems at $work, and we have had this setup from the first time\nsomebody did a forced push and broke things, which was like day 3 or\nsomething of our switchover to git from cvs, which is about two years\nago.\n\nIMO it would be nice if the reflog could be set to ONLY record forced\nupdates. This would make a lot of sense on a bare repo.\n\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"126797","messageId":"vpqzl729j72.fsf@bauges.imag.fr","threadId":"21482","inReplyTo":"alpine.DEB.1.00.0911041422170.2788@felix-maschine","subject":"Re: thoughts on setting core.logAllRefUpdates default true for bare repos","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-11-04T19:35:45Z","receivedAt":"2009-11-04T19:35:45Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n\n> I did not have time yet to investigate, but it seems that there are \n> problems with the permissions of shared bare repositories when activating \n> the reflogs.\n\nI can't think of any, and I just tried launching two\n\nwhile true; do git pull; date > foo.txt ; git add .; git commit -m \"xxx\"; git push; done\n\nin parallel, with two different users pushing to a --bare --shared\nrepository, and it did work well. But I may very well have missed\nsomething.\n\n(and actually, if it causes problem, it's an argument in favor of\ndefaulting to false when core.shared is true, not when core.bare).\n\n\nUnless I missed something, I think core.logAllRefUpdates should be\nenabled for bare repos.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"126803","messageId":"7v3a4ugjea.fsf@alter.siamese.dyndns.org","threadId":"21482","inReplyTo":"vpqzl729j72.fsf@bauges.imag.fr","subject":"Re: thoughts on setting core.logAllRefUpdates default true for bare repos","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-04T19:49:33Z","receivedAt":"2009-11-04T19:49:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> I can't think of any, and I just tried launching two\n>\n> while true; do git pull; date > foo.txt ; git add .; git commit -m \"xxx\"; git push; done\n>\n> in parallel, with two different users pushing to a --bare --shared\n> repository, and it did work well. But I may very well have missed\n> something.\n>\n> (and actually, if it causes problem, it's an argument in favor of\n> defaulting to false when core.shared is true, not when core.bare).\n>\n> Unless I missed something, I think core.logAllRefUpdates should be\n> enabled for bare repos.\n\nYour experiment justifies \"could be enabled safely\" and saying \"should be\"\nbased on that is a bit too strong and also premature.\n\nThe single most common reason why a bare repository is bare is because\nnobody regularly logs in to the machine that hosts it and goes there to\naccess its contents. As reflog is a local thing, and not exposed to\noutside world, enabling it alone would not help a lot to people who do not\nhave such a direct access to the bare repository, which by definition is\nthe majority because the reason why the repository is bare to begin with.\n\nOnce we add ways to expose information kept in reflog of a bare repository\nmore effectively and conveniently, the argument could become \"should be\nenabled now it would be very useful to have one\".\n\nI mentioned a possible option to show reflog entry annotations in gitweb.\nThat was an example of such an addition of \"a way to expose\".\n\nIt also is plausible to teach git-daemon a remote \"log\" request; similar\nto \"git fetch\" running \"upload-pack\" on the other end in the bare\nrepository, a \"git log --remote\" command may run \"upload-log\" on the other\nend and this service may allow passing the \"-g\" option when it does so.\nThat would be another addition of \"a way to expose\".\n"},{"id":"126825","messageId":"vpqr5se58e4.fsf@bauges.imag.fr","threadId":"21482","inReplyTo":"7v3a4ugjea.fsf@alter.siamese.dyndns.org","subject":"Re: thoughts on setting core.logAllRefUpdates default true for bare repos","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-11-04T20:42:43Z","receivedAt":"2009-11-04T20:42:43Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> I can't think of any, and I just tried launching two\n>>\n>> while true; do git pull; date > foo.txt ; git add .; git commit -m \"xxx\"; git push; done\n>>\n>> in parallel, with two different users pushing to a --bare --shared\n>> repository, and it did work well. But I may very well have missed\n>> something.\n>>\n>> (and actually, if it causes problem, it's an argument in favor of\n>> defaulting to false when core.shared is true, not when core.bare).\n>>\n>> Unless I missed something, I think core.logAllRefUpdates should be\n>> enabled for bare repos.\n>\n> Your experiment justifies \"could be enabled safely\" and saying \"should be\"\n> based on that is a bit too strong and also premature.\n\nRight, there were no cause/effect relationship between the first part\nand the \"should\".\n\n> As reflog is a local thing, and not exposed to outside world,\n> enabling it alone would not help a lot to people who do not have\n> such a direct access to the bare repository, which by definition is\n> the majority because the reason why the repository is bare to begin\n> with.\n\nFor sure, it's the majority. But it's not 100% cases either.\n\nAnd in most cases, even if the user doesn't have access to the repo,\nthere exists a sysadmin somewhere who has. And the day a user will\nsend a mail \"hey, I've messed up everything, I did a push -f and what\nhappened?\", this sysadmin will appreciate to have a log somewhere.\n\nAnd another use-case for the reflog is to find know reliable where a\npiece of code is comming from. \"git blame\" tells you who the commiter\nsaid he was, while the reflog says reliably who the push-er was.\n\nSo, clearly, the reflog on a bare repo is not usefull for daily use\nlike it is for non-bare repos (where, really, it's a killer\nfeature ;-) ). But it doesn't seem useless either, and it doesn't cost\nmuch, so ...\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"126853","messageId":"20091104235241.GA12984@vidovic","threadId":"21482","inReplyTo":"2e24e5b90911040841l7741787et48fabb8c8066e946@mail.gmail.com","subject":"Re: thoughts on setting core.logAllRefUpdates default true for bare repos","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2009-11-04T23:52:42Z","receivedAt":"2009-11-04T23:52:42Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 04/11/09, Sitaram Chamarty wrote:\n\n> But if you are able to do \"gc\" manually on any repo you can also do\n> \"reflog expire\" before \"gc\" can you not? Please correct me if I'm\n> wrong.\n\n\"If we are able to do 'gc' on any repo\"... But a lot of users aren't\nable to it because they aren't the admin.\n\nOr did you mean if \"non-admin users could\" ?\n\n-- \nNicolas Sebrecht\n"},{"id":"126856","messageId":"fabb9a1e0911041559m18a50d50r1b31aa99a1ce76aa@mail.gmail.com","threadId":"21482","inReplyTo":"20091104235241.GA12984@vidovic","subject":"Re: thoughts on setting core.logAllRefUpdates default true for bare repos","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-04T23:59:32Z","receivedAt":"2009-11-04T23:59:32Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Nov 5, 2009 at 00:52, Nicolas Sebrecht wrote:\n> Or did you mean if \"non-admin users could\" ?\n\nWe're talking about the case wherein a confidential object is pruned,\nregardless of whether it is a non-admin or admin user doing the\npruning, they should be able to 'reflog expire' if they can 'git gc'.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"126864","messageId":"2e24e5b90911041724u67a23278t6c0fc86a8ecc7d51@mail.gmail.com","threadId":"21482","inReplyTo":"20091104235241.GA12984@vidovic","subject":"Re: thoughts on setting core.logAllRefUpdates default true for bare repos","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-11-05T01:24:12Z","receivedAt":"2009-11-05T01:24:12Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Thu, Nov 5, 2009 at 5:22 AM, Nicolas Sebrecht wrote:\n> The 04/11/09, Sitaram Chamarty wrote:\n>\n>> But if you are able to do \"gc\" manually on any repo you can also do\n>> \"reflog expire\" before \"gc\" can you not?  Please correct me if I'm\n>> wrong.\n>\n> \"If we are able to do 'gc' on any repo\"... But a lot of users aren't\n> able to it because they aren't the admin.\n>\n> Or did you mean if \"non-admin users could\" ?\n\ndscho's original mail said: > With gitweb on a public site, there\nmight be a problem when you pushed\n> some blob containing trade secrets accidentally, and try to scrub the\n> repository using \"git gc\" after a forced push.\n\nThat's a manual gc. If you can do a manual gc, you can do a reflog\nexpire before the gc, is what I meant.\n\n>\n> --\n> Nicolas Sebrecht\n>\n"},{"id":"126865","messageId":"2e24e5b90911041728t72fe2c2fhbea5b8e707236fa@mail.gmail.com","threadId":"21482","inReplyTo":"7v3a4ugjea.fsf@alter.siamese.dyndns.org","subject":"Re: thoughts on setting core.logAllRefUpdates default true for bare repos","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-11-05T01:28:08Z","receivedAt":"2009-11-05T01:28:08Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Thu, Nov 5, 2009 at 1:19 AM, Junio C Hamano wrote:\n\n> The single most common reason why a bare repository is bare is because\n> nobody regularly logs in to the machine that hosts it and goes there to\n> access its contents.  As reflog is a local thing, and not exposed to\n> outside world, enabling it alone would not help a lot to people who do not\n> have such a direct access to the bare repository, which by definition is\n> the majority because the reason why the repository is bare to begin with.\n>\n> Once we add ways to expose information kept in reflog of a bare repository\n> more effectively and conveniently, the argument could become \"should be\n> enabled now it would be very useful to have one\".\n\nIt doesn't have to be exposed nor we have to wait till such features\n(like you mentioned gitweb, remote log, etc) are implemented.\n\nWe're talking \"disaster recovery\", not \"daily use\" -- after all,\n*someone* has access to the machine, and can become \"local\" to it.\n\nRegards,\n\nSitaram\n"}]}