Heads up, I'm gonna play the devil's advocate a little, here. On Sat, 2017-10-21 at 15:56 +0200, nicolas.mailhot@xxxxxxxxxxx wrote: > No that is not up to the hash function. First because hashes are too > long to be manipulated by humans, and second no hash will ever > capture human intent. You need an explicit human action to mark "I > want others to use this particular state of my project because I am > confident it is solid". > I would say you're just limiting your thoughts. There's no strict rule saying hash functions should be "incomprehensible" to humans or that different hashes should be "uncomparable". No one's going to stop someone from creating a hypothetical hash function that's totally ordered (!) unless you violate the basis of a "hash". (surprise, there's already attempts at it, https://stackoverflow.com/q/28043857/5614968 ) > Except, the releasing happens outside git, it's still fairly manual. You seem to be more frustrated by "manual" work. I suspect why you can't automate that. Given all the work done during a release of "Git", (https://public-inbox.org/git/xmqqr2tygvp4.fsf@xxxxxxxxxxxxxxxx.google. com/) may be the maintainer could possibly give some good advise on this. +cc Junio > All I'm proposing is to integrate the basic functions in git to > simplify the life of those projects and help smaller projects that > want completely intergrated git workflows. > Wait, aren't you just trying to make git more than a "version control system"? I don't think it's encouraged a lot here given that there have patches that have not been accepted because they might make git opinionated and the result "doesn't quite fit into the broad picture of a version control system" cf. https://public-inbox.org/git/20170711233827.23486-1-sbeller@xxxxxxxxxx/ cf. https://public-inbox.org/git/CAGZ79kYArf6R-vx1-Lm4X_ANLMrXc3VNd2aCQMnqq3J6y-s31Q@xxxxxxxxxxxxxx/ > Yes and it is so fun to herd hundreds of management tools with > different conventions and quirks. About as much fun as managing > dozens of scm before most projects settled on git. All commonalities > need to migrate in the common git layer to simplify management and > release id is the first of those. It's better to have a "good" (generic) release management tool that does what you ask (probably with some help from git) than try to turn Git into one (which is not possible without making Git opinionated, more on that later). I guess there should already be one that meets your expectation and you probably just have to discover it. Further, if there's no "generic" release management tool in existence, I suspect that because there's no such thing a "generic release management strategy" and it always depends on context (or) create one on your own in the spirit of letting "git" handle just "version control" and letting your "genereic" tool handle your concerns. Who knows, if you have developed a good enough "generic" tool it might be used widely for "release management" just as a lot of projects starting using Git for "version control". (I still suspect that there should be one that already exists) > > git tags ? > > Too loosely defined to be relied on by project-agnostic tools. That's > what most tools won't ever try to use those. Anything you will define > around tags as they stand is unlikely to work on the project of > someone else > They are loosely defined because you can't define them "tightly" and if you try to it would make Git opinionated !? > > > 5. a command, such as "git release", allow a human with control of the repo to set an explicit release version to a commit. > > > > This sounds fairly specific to an environment that you are in, maybe > > write git-release for your environment and then open source it. The > > world will love it (assuming they have the same environment and > > needs). > > If you take the time to look at it it is not specific, it is generic. > I would say that you might haven't looked broadly enough. 1) If it's generic, why isn't there any "generic" release management tool? 2) if it's possible to create a "generic" release management tool and it just doesn't exist yet, why not try to create instead of trying to integrate release management into Git ? (you could make it depend on git, of course) > You need to identify software during > its whole lifecycle, and the id needs to start in the scm, because > that's where the lifecycle starts. It might not for everyone! -- Kaartic
