{"thread":{"id":"27797","subject":"Re: [RFC] control, what refs are honored by core.logAllRefUpdates","startedAt":"2011-07-12T17:23:32Z","lastAt":"2011-07-13T08:59:15Z","messageCount":7,"participants":["Bert Wesarg","Junio C Hamano","Jeff King","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"171163","messageId":"CAKPyHN3_br-ndQo9oMzCcU1yOVEbAxmzvHQkwF15LgwQx12KZA@mail.gmail.com","threadId":"27797","inReplyTo":null,"subject":"Re: [RFC] control, what refs are honored by core.logAllRefUpdates","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2011-07-12T17:23:32Z","receivedAt":"2011-07-12T17:23:32Z","isPatch":false,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Mon, Jul 11, 2011 at 23:24, Junio C Hamano wrote:\n> Bert Wesarg writes:\n>\n>> The question is: should the user be able to disable logging of the\n>> hard-coded values. With your examples that would be possible. But I\n>> think we should not allow that.\n>\n> You have to justify that position. I do not see any reason to forbid\n> myself from declining reflog for refs/remotes/ while still logging the\n> updates to my refs/heads/.\n\nI don't, because I don't care. But I care for a simple way to always\nlog ref updates with update-ref. Thus, I take you justification for\nbeing able to do so and provide here a proposal for this:\n\nWhat: Control the refs which are honored by core.logAllRefUpdates.\n\nHow:\n\nIntroduce a new config variable named core.autoRefLog. This variable\nis a multi var. The default value is:\n\n [core]\n autoLogRef = heads\n autoLogRef = remotes\n autoLogRef = notes\n\nThis list must be initialize at runtime. Because older repositories\nwon't have them in existing config files.\n\nThe value given needs to be a valid ref, without leading or trailing\nslashes, and wildcards. The names will be prefixed with 'refs/' and\nsuffixed with '/'. The list is checked against the ref to update, if\nany of the values is a prefix of the given ref, than the update will\nbe logged, regardless whether the log file exists.\n\nSetting core.autoLogRef to the empty value, will reset the list.\n\nUsecase:\n\nTo be able to always log ref updates from update-ref in one call. For example:\n\n git -c core.logAllRefUpdates=true -c core.autoLogRef=frotz\nupdate-ref -mreason refs/frotz/master \n\nPlease note, that there is also the \"HEAD\" ref, which is honored by\ncore.logAllRefUpdates. I don't know how this should be handled by\ncore.autoLogRef. I have no problem that this will be hardcoded.\n\nKind regards,\nBert\n\nPS: I asked for the typo in my applied patch, but you are only on Cc,\nwhich should have been To. Please feel directly asked. Thanks.\n"},{"id":"171167","messageId":"7vaacj8jq7.fsf@alter.siamese.dyndns.org","threadId":"27797","inReplyTo":"CAKPyHN3_br-ndQo9oMzCcU1yOVEbAxmzvHQkwF15LgwQx12KZA@mail.gmail.com","subject":"Re: [RFC] control, what refs are honored by core.logAllRefUpdates","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-07-12T17:57:52Z","receivedAt":"2011-07-12T17:57:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bert Wesarg writes:\n\n> What: Control the refs which are honored by core.logAllRefUpdates.\n>\n> How:\n>\n> Introduce a new config variable named core.autoRefLog. This variable\n> is a multi var. The default value is:\n>\n> [core]\n> autoLogRef = heads\n> autoLogRef = remotes\n> autoLogRef = notes\n>\n> This list must be initialize at runtime. Because older repositories\n> won't have them in existing config files.\n\nIt sounds as if you mean to update .git/config when you find a repository\nthat is missing these, which is not what we want. I would rephrase it\nlike this:\n\n - The new variable core.autoLogRef is a multi-valued configuration.\n\n - If core.autoLogRef is defined (to any value), core.logAllRefupdates is\n ignored;\n\n - Otherwise, the core.logAllRefUpdates variable that is set to true is\n equivalent to having a \"reasonable default\" set in core.autoLogRef (and\n the current \"reasonable default\" happens to be heads, remotes and\n notes), and the core.logAllRefUpdates variable set to false (or\n missing) is equivalent to having an empty string in core.autoLogRef;\n\n> The value given needs to be a valid ref, without leading or trailing\n> slashes, and wildcards. The names will be prefixed with 'refs/' and\n> suffixed with '/'. The list is checked against the ref to update, if\n> any of the values is a prefix of the given ref, than the update will\n> be logged, regardless whether the log file exists.\n\nOk, except for:\n\n - An empty string in core.autoLogRef does not contribute to the matching\n logic above.\n\n> Setting core.autoLogRef to the empty value, will reset the list.\n\nIt is unclear what it is reset to. Do you mean it clears, e.g.\n\n [core]\n \tautoLogRef = heads\n \tautoLogRef = remotes\n autoLogRef = notes\n autoLogRef =\n autoLogRef = heads\n\nwould first create a list of three elements, clears it and then the final\nresult has only refs/heads/ in the list?\n"},{"id":"171170","messageId":"CAKPyHN0+BaPtrRMVrWCZQ2mbJQz_vxsOOsG4Z=Ksqc1RJvF1Ew@mail.gmail.com","threadId":"27797","inReplyTo":"7vaacj8jq7.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] control, what refs are honored by core.logAllRefUpdates","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2011-07-12T18:15:21Z","receivedAt":"2011-07-12T18:15:21Z","isPatch":false,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Tue, Jul 12, 2011 at 19:57, Junio C Hamano wrote:\n> Bert Wesarg writes:\n>\n>> What: Control the refs which are honored by core.logAllRefUpdates.\n>>\n>> How:\n>>\n>> Introduce a new config variable named core.autoRefLog. This variable\n>> is a multi var. The default value is:\n>>\n>>     [core]\n>>         autoLogRef = heads\n>>         autoLogRef = remotes\n>>         autoLogRef = notes\n>>\n>> This list must be initialize at runtime. Because older repositories\n>> won't have them in existing config files.\n>\n> It sounds as if you mean to update .git/config when you find a repository\n> that is missing these, which is not what we want.  I would rephrase it\n> like this:\n\nNo, that was not my intention. I meant that the list is set to the\ncurrent hard-coded list. And than subsequent code.autoLogRef values\nalter this list. So no 'conversion' will be done.\n\n>\n>  - The new variable core.autoLogRef is a multi-valued configuration.\n>\n>  - If core.autoLogRef is defined (to any value), core.logAllRefupdates is\n>   ignored;\n\nI haven't though of this logic. But it sounds good. Specifying any\ncore.autoLogRef should be honored, regardless whether\ncore.logAllRefupdates is set.\n\n>\n>  - Otherwise, the core.logAllRefUpdates variable that is set to true is\n>   equivalent to having a \"reasonable default\" set in core.autoLogRef (and\n>   the current \"reasonable default\" happens to be heads, remotes and\n>   notes), and the core.logAllRefUpdates variable set to false (or\n>   missing) is equivalent to having an empty string in core.autoLogRef;\n>\n>> The value given needs to be a valid ref, without leading or trailing\n>> slashes, and wildcards. The names will be prefixed with 'refs/' and\n>> suffixed with '/'. The list is checked against the ref to update, if\n>> any of the values is a prefix of the given ref, than the update will\n>> be logged, regardless whether the log file exists.\n>\n> Ok, except for:\n>\n>  - An empty string in core.autoLogRef does not contribute to the matching\n>   logic above.\n>\n>> Setting core.autoLogRef to the empty value, will reset the list.\n>\n> It is unclear what it is reset to.  Do you mean it clears, e.g.\n>\n>    [core]\n>        autoLogRef = heads\n>        autoLogRef = remotes\n>        autoLogRef = notes\n>        autoLogRef =\n>        autoLogRef = heads\n>\n> would first create a list of three elements, clears it and then the final\n> result has only refs/heads/ in the list?\n>\n\nExactly. I think the --notes option does have a similar semantics. (I\nadded Jeff to the Cc). There is --no-notes, which resets the notes\nlist and than subsequent --notes= options populate the list again.\n\nBert\n"},{"id":"171173","messageId":"20110712182517.GA17787@sigill.intra.peff.net","threadId":"27797","inReplyTo":"CAKPyHN0+BaPtrRMVrWCZQ2mbJQz_vxsOOsG4Z=Ksqc1RJvF1Ew@mail.gmail.com","subject":"Re: [RFC] control, what refs are honored by core.logAllRefUpdates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-07-12T18:25:17Z","receivedAt":"2011-07-12T18:25:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 12, 2011 at 08:15:21PM +0200, Bert Wesarg wrote:\n\n> >> Setting core.autoLogRef to the empty value, will reset the list.\n> >\n> > It is unclear what it is reset to.  Do you mean it clears, e.g.\n> >\n> >    [core]\n> >        autoLogRef = heads\n> >        autoLogRef = remotes\n> >        autoLogRef = notes\n> >        autoLogRef =\n> >        autoLogRef = heads\n> >\n> > would first create a list of three elements, clears it and then the final\n> > result has only refs/heads/ in the list?\n> >\n> Exactly. I think the --notes option does have a similar semantics. (I\n> added Jeff to the Cc). There is --no-notes, which resets the notes\n> list and than subsequent --notes= options populate the list again.\n\nYeah, --notes versus --no-notes is as you say. This topic came up\nrecently when discussing config for the user-defined archive filters,\ntoo. This is a fairly natural solution, as it lets you say \"append to\nwhat's there\" versus \"replace what's there\", which is what you really\nwant[1].\n\nI think I'd rather see something more syntactically explicit for\nresetting, though, like:\n\n [core]\n autoLogRef = heads\n autoLogRef = remotes\n autoLogRef = notes\n !autoLogRef\n autoLogref = heads\n\n(for that matter, I have often wished that \"!autoLogRef\" was boolean\nfalse, just as \"autoLogRef\" is boolean true). But it may not be worth\nchanging the config syntax for.\n\n-Peff\n\n[1] If we were starting from scratch, you could make that distinction\nwith a new operator, like:\n\n [core]\n autoLogRef = heads\n autoLogRef += remotes\n autoLogRef += notes\n autoLogRef = heads\n\nwhich would be equivalent to what you wrote above. But because it\nswitches the semantics of \"=\" to \"replace\" instead of \"append\" for\nmulti-value keys, it would break all current config that uses multiple\n\"fetch\" lines (for example).\n"},{"id":"171195","messageId":"20110712222129.GA15994@elie","threadId":"27797","inReplyTo":"20110712182517.GA17787@sigill.intra.peff.net","subject":"Re: [RFC] control, what refs are honored by core.logAllRefUpdates","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-07-12T22:21:29Z","receivedAt":"2011-07-12T22:21:29Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> I think I'd rather see something more syntactically explicit for\n> resetting, though, like:\n>\n> [core]\n> autoLogRef = heads\n> autoLogRef = remotes\n> autoLogRef = notes\n> !autoLogRef\n> autoLogref = heads\n>\n> (for that matter, I have often wished that \"!autoLogRef\" was boolean\n> false, just as \"autoLogRef\" is boolean true). But it may not be worth\n> changing the config syntax for.\n\nSounds worthwhile to me. I've (probably irrationally) wished before\nfor an abbreviation for \"bare = false\", too.\n"},{"id":"171225","messageId":"CAKPyHN1GEkcyacQ_f4hhjaaZx4Fx4tmfz0qRSfTPXJDgUm8mow@mail.gmail.com","threadId":"27797","inReplyTo":"20110712182517.GA17787@sigill.intra.peff.net","subject":"Re: [RFC] control, what refs are honored by core.logAllRefUpdates","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2011-07-13T08:52:58Z","receivedAt":"2011-07-13T08:52:58Z","isPatch":false,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Tue, Jul 12, 2011 at 20:25, Jeff King wrote:\n [1] If we were starting from scratch, you could make that distinction\n> with a new operator, like:\n>\n>  [core]\n>    autoLogRef = heads\n>    autoLogRef += remotes\n>    autoLogRef += notes\n>    autoLogRef = heads\n>\n> which would be equivalent to what you wrote above. But because it\n> switches the semantics of \"=\" to \"replace\" instead of \"append\" for\n> multi-value keys, it would break all current config that uses multiple\n> \"fetch\" lines (for example).\n\nAdding ! as a negator would also break config files read by old git versions.\n\nBert\n\n>\n"},{"id":"171226","messageId":"20110713085915.GA29900@sigill.intra.peff.net","threadId":"27797","inReplyTo":"CAKPyHN1GEkcyacQ_f4hhjaaZx4Fx4tmfz0qRSfTPXJDgUm8mow@mail.gmail.com","subject":"Re: [RFC] control, what refs are honored by core.logAllRefUpdates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-07-13T08:59:15Z","receivedAt":"2011-07-13T08:59:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 13, 2011 at 10:52:58AM +0200, Bert Wesarg wrote:\n\n> On Tue, Jul 12, 2011 at 20:25, Jeff King wrote:\n> [1] If we were starting from scratch, you could make that distinction\n> > with a new operator, like:\n> >\n> >  [core]\n> >    autoLogRef = heads\n> >    autoLogRef += remotes\n> >    autoLogRef += notes\n> >    autoLogRef = heads\n> >\n> > which would be equivalent to what you wrote above. But because it\n> > switches the semantics of \"=\" to \"replace\" instead of \"append\" for\n> > multi-value keys, it would break all current config that uses multiple\n> > \"fetch\" lines (for example).\n> \n> Adding ! as a negator would also break config files read by old git versions.\n\nTrue. I consider that less bad than \"existing config files are broken\",\nbut it is still worth thinking about. It really only affects people who\nmove back and forth between git versions using the same set of config\nfiles.\n\nIn general, our config stays pretty compatible between versions, but\nthere are exceptions. E.g., older versions of git will complain about:\n\n [pager]\n log = whatever\n\nbecause \"pager.*\" previously had to be a bool. I run into this when\ntesting old git versions.\n\nI have no idea how common that sort of thing is with regular users,\nthough.\n\n-Peff\n"}]}