From: Eric Blake <eblake@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] configure: save git working tree information in "pkgversion"
Date: Tue, 31 May 2016 11:45:25 -0600 [thread overview]
Message-ID: <574DCDB5.5000208@redhat.com> (raw)
In-Reply-To: <8d55914d-e57c-43e3-5319-28db331de5f8@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]
On 05/31/2016 11:01 AM, Laszlo Ersek wrote:
>>> Grepping git's Documentation/RelNotes/ directory, I find:
>>> - in "1.6.6.txt": the introduction of --dirty
>>> - in "1.7.6.4.txt": an apparently important bugfix for --dirty
>>>
>>> Version 1.7.6.4 of git was tagged on Sep 23 2011.
>>>
>>> Does this information help in deciding if we can use --dirty?
>>
>> 5 years old sounds new enough for my liking :-)
>>
>> I guess we could use --dirty and catch the non-zero exit code and just
>> re-try without --dirty.
>
> But, if we can't use --dirty, I should probably use the plus-sign
> fallback (we need *something* to mark a dirty state).
>
> In which case however, shouldn't we just go with the current patch,
> which doesn't care about --dirty at all? Otherwise, some build hosts
> will append "-dirty", and others will append "+".
>
> IMO we should either require --dirty, or go with the current patch.
Gnulib's build-aux/git-version-gen script doesn't yet use --dirty, but
may be an inspiration for how to generate the same suffix:
# Test whether to append the "-dirty" suffix only if the version
# string we're using came from git. I.e., skip the test if it's "UNKNOWN"
# or if it came from .tarball-version.
if test "x$v_from_git" != x; then
# Don't declare a version "dirty" merely because a time stamp has changed.
git update-index --refresh > /dev/null 2>&1
dirty=`exec 2>/dev/null;git diff-index --name-only HEAD` || dirty=
case "$dirty" in
'') ;;
*) # Append the suffix only if there isn't one already.
case $v in
*-dirty) ;;
*) v="$v-dirty" ;;
esac ;;
esac
fi
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2016-05-31 17:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 15:04 [Qemu-devel] [PATCH] configure: save git working tree information in "pkgversion" Laszlo Ersek
2016-05-31 15:14 ` Daniel P. Berrange
2016-05-31 15:40 ` Laszlo Ersek
2016-05-31 15:43 ` Daniel P. Berrange
2016-05-31 17:01 ` Laszlo Ersek
2016-05-31 17:45 ` Eric Blake [this message]
2016-05-31 21:16 ` Laszlo Ersek
2016-06-01 8:55 ` Laszlo Ersek
2016-06-01 9:11 ` Fam Zheng
2016-06-01 9:36 ` Kashyap Chamarthy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=574DCDB5.5000208@redhat.com \
--to=eblake@redhat.com \
--cc=berrange@redhat.com \
--cc=lersek@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).