On Sat, Sep 7, 2013 at 6:10 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> If you want to give build a custom name, >>> >>> echo buildname >version >>> >>> should be sufficient, no? >> >> That's not sufficient if you care about a proper (automated) release >> workflow with your releases tagged. > > I take the above "your" does not refer to "mine, Junio's". Right, I was not meaning to refer to you personally or Git as a project, but "anyone's project". > I am not sure what you mean by automated, but if you can tell your > automation infrastructure that the way to build this Git software is > to run "make" in it, shouldn't it be trivial to instead tell it to > run something like this instead? > > git describe --tags HEAD >version && make It probably would be trivial, but I'd like to use as much of upstream Git's build logic as possible without the need to create a custom file. > Or are these tags you want G-V-G to use also droppings of the > automated process? That is, what you tell the automation > infrastructure is to run something like this? > > git tag build-$(date +"%Y-%m-%d") && make Sort of. I manually tag a commit as "good for testing", and the CI server that's watching for new tags in the repo then builds my custom Git from that tag and runs the tests. If all tests pass the custom Git binaries are packaged and uploaded to a binary artifact server. I'd like the version that git reports as well as the version that's included in the binary artifact file names to be directly derived from the tag. I simply do not like the idea of having a tag *and* a version file, even if the version file is derived from the tag, simply because there's still a slight chance that the tag and version file might diverge due to some mistake / error / bug. > I do not think the current use of "describe" helps the builder to > avoid making a light-weight tag by mistake anyway, as it would be > very natural to update DEF_VER to a matching string. In a month or > so, I am sure I'd update that line to v1.8.5 before I make a tag > with the same name, and it does not matter if the current use of > "describe" skipped a mistakenly-made lightweight v1.8.5 tag when > deciding the embedded version string---the end result will get the > same string from DEF_VER and running "git version" with the built > binary will happily show v1.8.5 the same way. Which raises another question on my side: Isn't it tedious for you to both update DEF_VER *and* tag a version? Wouldn't it probably be less error prove (in the sense of keeping DEF_VER and tagged version in sync) to remove DEF_VER completely and just die if all ways to derive a Git version fail? > I am however still curious what kind of other tags (either signed, > annotated, or lightweight) you are using for this purpose. Is there In general, so far I had very little use for other tags than lightweight tags. That's mainly because I believe my stuff is not "important" enough to be signed, and I rarely have something to say about a tag besides its name. Most annotate tags I've seen so far are just trivial variations of the tag name, anyway. > a case where you have your own tag that points at the exact version > as I tagged? In such a case, do you have a preference on which tag No. I always carry patches on top. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html