"Philip Oakley" <philipoak...@iee.org> writes: >> If the "parsing" is done for white/blacklist purposes, is there a >> need to straight-jacket the verison string format like this series? > > The purpose is to document what we felt we could guarantee, and that > which was open to variation, so that those, like the Git-Gui, can code > in a sensible check for the version. Two digits (X.Y) should pass the > existing Git Gui check. > > I'll drop the length limit, and keep to an X.Y check > > Is the end of t0000-basic.sh a sensible place for the check?
Sorry, but I still do not understand what you are trying to achieve. What kind of benefit are you envisioning out of this? For a future version, people would not know what incompatibilities it would introduce, so case "$(git version)" in "git verison"[2-9].*) echo unsupported version exit 1 ;; esac is a nonsense check. For all released versions, people know how they looked like and we do not have anything further to specify. Git 1.5.0 will forever identify itself as: $ git version git version 1.5.0 Worse yet, for an untagged version, you may get something like git version 22.214.171.124-515-g78d2372 and it may or may not behave the same way as 126.96.36.199 depending on what trait you are interested in. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html