Re: [PATCH] help.c: add a compatibility comment to cmd_version()

From: Philip Oakley <philipoakley@iee.org>
Date: Apr 18, 2013, 23:00 UTC
Message-ID: <046DF03A85924057935F3EB1064DC27B@PhilipOakley>
In-Reply-To: <7vehe8d7bq.fsf@alter.siamese.dyndns.org>

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Thursday, April 18, 2013 1:13 AM

Show 11 quoted lines

> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> How about
>>    * E.g. git gui uses the extended regular expression "^git version
>> [1-9]+(\.[0-9]+)+.*"
>>    * to check for an acceptable version string.
>>
>> The ERE is from git-gui.sh:L958.
>
> That is exactly the kind of guarantee we do _not_ want to give.
>

So you are trying to avoid giving _any_ "guarantee" about what visible manifestation a user may obtain about a system that passes the test suite we have set out. I was hoping we could give a basic minimum indication of the expected style of the version string for a git which *passes* our tests. But like you say, it doesn't form a real guarantee - caveat emptor still applies.

Show 9 quoted lines

>> ... Hence my suggestion of the basic test that a "passing" git
>> would produce a consistent version string.
>
> I have been assuming that you are trying to avoid an exchange like
> this one we had in the past:
>
> 
> http://thread.gmane.org/gmane.comp.version-control.git/216923/focus=217007
>

In a sense yes. As David noted, others do attempt to trust us via our current version string format. I thought it worthwhile (given my earlier 'mistake' in 216923/focus=216925) to suggest such a basic indication of our current string style.

Show 13 quoted lines

> I also have been assuming that you are pushing to limit the possible
> versioning scheme, but I do not know what that extra limitation
> would achieve in the real world.
>
> By sticking to the pattern "git gui" happens to use, "git gui" may
> be able to guess that the next version of Git says it is verison
> "1.8.3".  That is the _only_ thing your "test" buys.
>
> But having parsed the "1.8.3" substring out of it, "git gui" does
> not know anything about what 1.8.3 gives it.  As far as it is
> concerned, it is a version whose "git version" output it has never
> seen (unless it has been kept up to date with the development of
> Git).

You are focusssing on the wrong side of issue (from my viewpoint). If my earlier patch had gone in, it would have passsed our tests but not played nicely with the community tools. That would have been IMHO a regression, so from my viewpoint I believed it was worth having a test to avoid such a 'regression'.

Show 10 quoted lines

>
> By matching against "git version [1-9]+(\.[0-9]+)+", it is accepting
> that future versions may break assumptions it makes for some known
> versions (which is warranted) and all future versions (which is
> unwarranted) of Git.  Maybe the version 2.0 of Git adds all changes
> in the directory "d", including removals, when you say "git add d",
> but it may have assumed that with Git version 1.5.0 or newer, saying
> "git add d" would result in added and modified inside that directory
> getting updated in the index, but paths removed from the working
> tree will stay in the index.

If it was a gross incompatibility then (a) we are likley to be signalling it for a while, and (b) other tools would need updating as well, and they would hope that they could 'read' the version in a consistent style. We would also still have the choice of changing our existing string style, which would explicitly signal a change via the test fail.

Show 8 quoted lines

>
> The only thing the scripts that read from the output of "git
> version" can reliably tell is if it is interacting with a version of
> Git it knows about.  If it made any unwarranted assumption on the
> versions it hasn't seen, it has to be fixed in "git gui" _anyway_.
>
> Of course, we would not change the output of "git version"
> willy-nilly without good reason, but that is a different topic.

Ah. I thought it was the [original] topic. I was calibrating the willy-nillyness ;-)

Show 5 quoted lines

>
> So I do not know what you want to achieve in the real world with
> that extra limitation on the "git version" output format.
>
> Maybe you are proposing something else.  I dunno.

I was just using a slightly different philosophical approach.

> --

Philip