On Tue, Jul 12, 2011 at 19:57, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> writes: > >> What: Control the refs which are honored by core.logAllRefUpdates. >> >> How: >> >> Introduce a new config variable named core.autoRefLog. This variable >> is a multi var. The default value is: >> >> [core] >> autoLogRef = heads >> autoLogRef = remotes >> autoLogRef = notes >> >> This list must be initialize at runtime. Because older repositories >> won't have them in existing config files. > > It sounds as if you mean to update .git/config when you find a repository > that is missing these, which is not what we want. I would rephrase it > like this: No, that was not my intention. I meant that the list is set to the current hard-coded list. And than subsequent code.autoLogRef values alter this list. So no 'conversion' will be done. > > - The new variable core.autoLogRef is a multi-valued configuration. > > - If core.autoLogRef is defined (to any value), core.logAllRefupdates is > ignored; I haven't though of this logic. But it sounds good. Specifying any core.autoLogRef should be honored, regardless whether core.logAllRefupdates is set. > > - Otherwise, the core.logAllRefUpdates variable that is set to true is > equivalent to having a "reasonable default" set in core.autoLogRef (and > the current "reasonable default" happens to be heads, remotes and > notes), and the core.logAllRefUpdates variable set to false (or > missing) is equivalent to having an empty string in core.autoLogRef; > >> The value given needs to be a valid ref, without leading or trailing >> slashes, and wildcards. The names will be prefixed with 'refs/' and >> suffixed with '/'. The list is checked against the ref to update, if >> any of the values is a prefix of the given ref, than the update will >> be logged, regardless whether the log file exists. > > Ok, except for: > > - An empty string in core.autoLogRef does not contribute to the matching > logic above. > >> Setting core.autoLogRef to the empty value, will reset the list. > > It is unclear what it is reset to. Do you mean it clears, e.g. > > [core] > autoLogRef = heads > autoLogRef = remotes > autoLogRef = notes > autoLogRef = > autoLogRef = heads > > would first create a list of three elements, clears it and then the final > result has only refs/heads/ in the list? > Exactly. I think the --notes option does have a similar semantics. (I added Jeff to the Cc). There is --no-notes, which resets the notes list and than subsequent --notes= options populate the list again. Bert -- 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