On 10.08.2015 19:46, Patrick Georgi wrote:
I wanted to note that mercurial can use git servers in the backend: http://hg-git.github.io/
Hm. That sounds promising, thanks.
On 08.08.2015 15:04, Patrick Georgi wrote:
2015-08-08 10:23 GMT+02:00 Carl-Daniel Hailfinger <email@example.com mailto:firstname.lastname@example.org>:
If there really is a large demand for a non-svn hosting, I would be open to using mercurial (as master) because it at least has some sort of usability and can provide (conceptually limited) version numbers. I have worked for a few years with mercurial and the version numbers are extremely helpful even if they are per-branch and only semi-stable.
mercurial's notion of a monotonic commit counter (that you're looking for if I understand you correctly) has about the same quality as git describe's commits-since-last-tag counter.
For a global numbering scheme, you could just (automatically) tag every single commit of a certain branch (master, release, ...) with a monotonic counter. That's more or less what the svn-to-git translation of tianocore is doing, for example (with tags following the scheme svn18670). That way, those numbers are actually global, unlike what mercurial is doing. Assume that the scheme is to use $version-$number since release: git describe would emit something like 0.9.9-40-5-gabcde, meaning that your tree is based on the tag 0.9.9-40 (globally unique), is 5 local commits away from that, with your current local commit id being abcde.
The auto-tag of every commit sounds like an option I could agree with. It would preserve the convenience of the global strong svn commit ID even for git. However, I don't know if this would be acceptable for Stefan (especially from a merging perspective).