Re: [PATCH 8/8 v6] gitweb: Add an option to force version match

Jakub Narebski [off-list ref] writes:

On Mon, 1 Feb 2010, at 17:01:37 -0800, J.H. wrote:

quoted

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?