v2, 2 partsversion-gen: cleanup

Felipe Contreras (2):
  version-gen: cleanup
  version-gen: avoid messing the version

 GIT-VERSION-GEN | 36 +++++++++++++++++++-----------------
 1 file changed, 19 insertions(+), 17 deletions(-)

No functional changes.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 GIT-VERSION-GEN | 36 ++++++++++++++++++++----------------
 1 file changed, 20 insertions(+), 16 deletions(-)

Felipe Contreras <felipe.contreras@gmail.com> writes:

Makes sense; using a helper function makes the primary logic easier to read.

The point of this part is "if the version file is already up to date, do not rewrite it only to smudge the mtime to confuse make", so it would be much easier to read to write it like so:

	if test "$VN" != "$VC"
        then
		... two echoes ...
	fi

compared to "exiting in the middle" which is harder to follow, especially if we consider that we may have to grow the remaining two lines in the future.

On Fri, Sep 13, 2013 at 1:10 AM, Junio C Hamano <gitster@pobox.com> wrote:

No, it's much easier to follow, the code clearly says "if the version is up to date, there's nothing else to do".

If the version is 'v1.8.4-rc1' that is the version, and there's no need to change it to anything else, like 'v1.8.4.rc1'.

If RedHat, or somebody else, needs a specific version, they can use the 'version' file, like everybody else.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 GIT-VERSION-GEN | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

Felipe Contreras <felipe.contreras@gmail.com> writes:

I already explained to you why this is a bad change.

When we say "we try to avoid regressions", we really mean it. Before coming up with a change to pay Paul by robbing Peter, we must make an honest effort to see if there is a way to pay Paul without robbing anybody.

This change forces existing users who depend on how dashes are mangled into dots to change their tooling.

We do occasionally make deliberate regressions that force existing users to change the way they work, but only when there is no other way, and when the benefit of the change far outweighs the cost of such an adjustment, and with careful planning to ease the pain of transition. The updates to "git add" and "git push" planned for 2.0 fall into that category.

There has to be a benefit that far outweighs the inconvenience this patch imposes on existing users, but I do not see there is any. "If somebody needs a specific version, they can use the 'version' file" does not justify it at all; it equally applies to those who want to use a version name with a dash.

Besides, the patch does not even do what it claims to do; if the version is "v1.8.4-rc1", what you get out of the updated code is "1.8.4-rc1", still losing the leading "v".

I'd be more receptive if the patch were like this instead, though.

On Fri, Sep 13, 2013 at 1:16 PM, Junio C Hamano <gitster@pobox.com> wrote:

No, you did not.

All you did is throw a non sequitur argument which I already exposed as such.

Maybe by "regressions" you mean progress.

There is, because Peter, the RedHat maintainer, can do exactly the same that Alice does; use the 'version' file.

In fact, Peter, cannot possibly use Git's version because of this:

% rpmdev-vercmp git-1.8.4 git-1.8.4.rc1 git-1.8.4 < git-1.8.4.rc1 % rpmdev-vercmp git-1.8.4 git-1.8.4-rc1 git-1.8.4 < git-1.8.4-rc1 % rpmdev-vercmp git-1.8.4 git-1.8.4~rc1 git-1.8.4 > git-1.8.4~rc1

Fedora's guideline[1] is to use a format like git-1.8.4-1.rc1, then the final release would be git-1.8.4-2, in other words, the '.rc1' is mostly informative, but that has nothing to do with Git's internal version (git-1.8.4.rc1).

openSUSE's guideline[1] prefers to use git-1.8.4~rc1.

Either way, none of them could possibly use git-1.8.4.rc1, because that's greater than git-1.8.4.

No, it does not.

You just say that, and you assume because you said it, it must be true; it's not.

First of all, nor RedHat, nor any other RPM-based distribution needs this any more, because as a simple search demonstrates, they don't use release candidates any more.

http://www.rpmfind.net/linux/rpm2html/search.php?query=git&submit=Search+...

Essentially, Peter is a figment of your imagination.

The closest thing to Peter 1) doesn't use release candidates, and 2) if he did, he wouldn't use a version like git-1.8.4.rc1.

Wrong.

% git tag -m '' v1.8.5-rc1 % ./GIT-VERSION-GEN GIT_VERSION = 1.8.5-rc1-dirty

[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#NonNumericRelease [2] http://en.opensuse.org/openSUSE:Package_naming_guidelines