Jakub Narebski <jnareb@xxxxxxxxx> writes: > On Mon, 1 Feb 2010, at 17:01:37 -0800, J.H. wrote: > >> Starting to pop off the stack, and this came up first. A quick reading >> of this, I'd sign-off and agree to patches 1-7 completely. >> >> I'm still going to take issue that this being off by default is the >> wrong behavior and leaving this off by default more or less means that >> it will never get run and it becomes useless code. If this isn't on by >> default, it shouldn't be committed, as I can't think of a legitimate use >> case where an admin is going to turn this on. > > Well, I don't think that mismatched git and gitweb version should be > serious problem in practice, unless they are seriously out of sync. > And in such situation (where either git is stale and gitweb updated, > or git updated and gitweb kept stale e.g. because it is heavily > customized with not ported changes) gitweb admin should turn this > feature on. I am not quite sure why the "boolean" default matters that much to deserve this much of bandwidth. If it is assumed that most everybody uses matching git and gitweb given by their distro, then the default does not matter to them. So let's think about others. If it is by default on, then here are what the site administrators would do: - Some may want to _always_ make sure they run matching versions and consider having different versions of git and gitweb as _a mistake_; . they leave the check on by default, and they don't have to do anything. - Some may _not_ even care. They flip it off, and keep it that way. They do that _only_ once. Between these two classes of people, if you make the default off, you are making more careful ones pay a bit more "one time" price, while allowing lazy ones potentially shoot themselves in the foot more easily. As the maintainer, I am sympathetic John's insistence of having this check on by default, and would even suggest that the configuration variable has to be set to the exact string "I accept the risk of running non-matching versions of git and gitweb" to turn the warning off ;-), but either way, it doesn't seem to make too much of a difference. Admittedly, unlike John or Pasky, I do not run a public gitweb instanace nor have to deal with error reports from the end users, and that might be contributing to my bias. But I think we need to try helping the third category of people: - Some may need to _keep_ unmatched versions of git and gitweb for the users on their box. Perhaps interactive users need a certain version of git, but they want to show spiffier looking gitweb to the general public by installing newer one. They check if the combination of the particular (older) git and (newer) gitweb work well together, and then they say "don't warn, I know it is Ok _now_". Unless the configuration can express "this combination has been checked, so do not warn, but do warn when any other untested combination is being used", this class of people won't be helped by having a configuration. They instead have to _remember_ that they need to flip the warning bit on before updating their git and/or gitweb, only to get reminded that they need to make sure the combination works well. That's a funny chicken-and-egg problem, isn't it? -- 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