Re: [RFC/PATCH 0/2] Test the Git version string

From: David Aguilar <davvid@gmail.com>
Date: Apr 16, 2013, 18:24 UTC
Message-ID: <CAJDDKr7WKwt10sCRTbm8gdhwEUKSYuQxtPDVm7usTm2ZHryk9g@mail.gmail.com>
In-Reply-To: <7v8v4imjji.fsf@alter.siamese.dyndns.org>

On Tue, Apr 16, 2013 at 11:12 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 22 quoted lines

>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
> >> What kind of benefit are you envisioning out of this?
> >
> > The purpose of tests is to detect mistakes and spot regressions.
> >
> > A change to the 'git version X.Y.z' string would be a regression, as I
> > spotted earlier, as it conflicts with expectations of standard
> > programmes such as git-gui.
>
> Sorry, but I do not follow.
>
> A released version says "git version 1.8.2.1".  In a month or so,
> I'll have another one that says "git version 1.8.3".  Or I may
> decide to bump in preparation for 2.0 and it may identify itself as
> "git version 1.9".
>
> Neither of which no existing "program such as git-gui" has ever
> seen.
>
> In what way is that a regression?

Sorry.  I was the one that first suggested that this was an issue.

The "regression" is that there are scripts and tools in the wild that need to know the git version when deciding whether or not to use some new feature.

e.g. "git status --ignore-submodules=dirty" did not appear until git 1.7.2. A script may want to use this flag, but it will only want to use it when available.

If this string started saying "The Git Version Control System v2.0" then these scripts would be "broken" since they would no longer recognize this as a "post-1.7.2 Git".

The unstated suggestion here is that it may be helpful to others if we were to declare that the "git version" output is plumbing.

Folks are already using it that way so making it official would provide a guarantee that we won't break them in the future. -- David