Re: [Lazarus] GIT sha1 vs svn numbers
This was meant to go to some one else. autocompletion of mail addresses -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] GIT sha1 vs svn numbers
On 13/02/2019 22:24, Martin Frb via lazarus wrote: > I looked at a few ideas, if something like the svn numbers could be > retained. Why would you want to shoehorn Git (a distributed version control system) into the way SubVersion (a client/server based version control system) works? They are fundamentally different. Yes Git can be used kind-of like a client/server version control system, but then you loose pretty much all the functionality that makes a distributed version control system so much better. Anyway, I'm not 100% sure what you want to achieve, but do you know the git-describe command? https://git-scm.com/docs/git-describe It gives you a version-like result. A version (tag or branch name - tag by default), number of commits since that 'major event' in the repository history, and then the SHA1 of the actual commit you are on. eg: $ git describe v1.4.1-903-g6e8a7fbb That output means the current HEAD commit is a descendant of "v1.4.1" tag. It has 903 commits since the "v1.4.1" tag. The HEAD commit's SHA1 value is 6e8a7fbb. The "g" prefix is simply to say "git" was used. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] GIT sha1 vs svn numbers
I looked at a few ideas, if something like the svn numbers could be retained. One approach would be to have a tag on each commit. That would mean that r54123 would be a replacement for the sha1 in almost all (if not all) situations. Not tested, but likely that the server can add the tags, when stuff gets pushed. The downsides: - might slightly slow down "git log" (not much really) - "git tag" which usually lists tags like releases, will list 5+ revisions too viewing tags in GUI frontends may take serious time, as GUI frontends seem not to expect this (tested with tortoise / tortoise revision graph even crashes with that) - may interfere otherwise when tagging releases etc / need to push new tags individually by name. Another approach would be to include such info in the commit-message. But that has to be done with the commit. That is locally by each user. (by a local git hook script). Therefore those refs would not be unique. Duplicates are possible. This is similar to the "git-svn-id" present in the commit message of all imported commits. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
