Is there a way to get human readable version numbers again, like in the SVN times? This is a small annoying thing that is really unimportant compared to other newborn problems. Earlier we had a decimal number that had some meaning. Now there is a long hexa string that informs only machines.
A version number is an ill-defined concept for a distributed version control system (if we both commit something locally after commit 1234, which one is really 1235?), but the system used by version.py is
git rev-list HEAD | wc -l
but this is *not *the same number that would be returned by an SVN checkout from github.
Merlijn
On 15 January 2014 12:38, Bináris wikiposta@gmail.com wrote:
Is there a way to get human readable version numbers again, like in the SVN times? This is a small annoying thing that is really unimportant compared to other newborn problems. Earlier we had a decimal number that had some meaning. Now there is a long hexa string that informs only machines.
-- Bináris
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
I am afraid I don't really understand you. Was there any real problem with SVN version numbers? What kind of local commit? There was one system with one series of numbers. Do you mean your own computer by local? That is not interesting for public.
The old version number HAD some meaning. It gave a sort order, some help where to put a script in my mind. This new system is only useful for computers. Well, we can live together with that, but if there is any chance to install some human readable version, I would appreciate it.
2014/1/15 Merlijn van Deen valhallasw@arctus.nl
A version number is an ill-defined concept for a distributed version control system (if we both commit something locally after commit 1234, which one is really 1235?), but the system used by version.py is
git rev-list HEAD | wc -l
but this is *not *the same number that would be returned by an SVN checkout from github.
Merlijn
On 15 January 2014 12:38, Bináris wikiposta@gmail.com wrote:
Is there a way to get human readable version numbers again, like in the SVN times? This is a small annoying thing that is really unimportant compared to other newborn problems. Earlier we had a decimal number that had some meaning. Now there is a long hexa string that informs only machines.
-- Bináris
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
On 15 January 2014 13:47, Bináris wikiposta@gmail.com wrote:
I am afraid I don't really understand you. Was there any real problem with SVN version numbers? What kind of local commit? There was one system with one series of numbers. Do you mean your own computer by local? That is not interesting for public.
Reading a git tutorial (or two) might help to understand the issue. To help understand the differences from SVN, http://hginit.com/00.html is really helpful - it's written for mercurial, but you can just read 'git' everywhere 'hg' or 'mercurial' is used.
The old version number HAD some meaning. It gave a sort order, some help where to put a script in my mind. This new system is only useful for computers. Well, we can live together with that, but if there is any chance to install some human readable version, I would appreciate it.
I have given you the exact command that you can use to get 'a human readable, incrementing version number'. But I've asked this before, and I'll ask it again: why do you need a revision number? What is the use case, and why couldn't that use case also be handled by a revision hash?
Merlijn
Another thing that I think it's important is the difference between git and svn is the way you can commit. In svn it's linear, you commit after another commit but in git it's like a tree you can make branches and merge them with the main branch seperately so a number can't be a good way of determination of current version On Jan 15, 2014 11:28 PM, "Merlijn van Deen" valhallasw@arctus.nl wrote:
On 15 January 2014 13:47, Bináris wikiposta@gmail.com wrote:
I am afraid I don't really understand you. Was there any real problem with SVN version numbers? What kind of local commit? There was one system with one series of numbers. Do you mean your own computer by local? That is not interesting for public.
Reading a git tutorial (or two) might help to understand the issue. To help understand the differences from SVN, http://hginit.com/00.html is really helpful - it's written for mercurial, but you can just read 'git' everywhere 'hg' or 'mercurial' is used.
The old version number HAD some meaning. It gave a sort order, some help where to put a script in my mind. This new system is only useful for computers. Well, we can live together with that, but if there is any chance to install some human readable version, I would appreciate it.
I have given you the exact command that you can use to get 'a human readable, incrementing version number'. But I've asked this before, and I'll ask it again: why do you need a revision number? What is the use case, and why couldn't that use case also be handled by a revision hash?
Merlijn
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
Le 15/01/14 12:38, Bináris a écrit :
Is there a way to get human readable version numbers again, like in the SVN times? This is a small annoying thing that is really unimportant compared to other newborn problems. Earlier we had a decimal number that had some meaning. Now there is a long hexa string that informs only machines.
Hello,
If your repository has tagged some commit, you can use 'git describe' which will find the nearest tag, count the commit and forge a version for you out of it. Something like:
$ git describe 2.0.0-24-g709bc9a
Which mean:
Version 2.0.0 + 24 commits
The last commit is a git commit having sha1 709bc9a.
You would need at least one tag though.
pywikipedia-l@lists.wikimedia.org