On Sat, Sep 7, 2013 at 6:10 PM, Junio C Hamano <gits...@pobox.com> 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
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html