git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@shadowen.org>
To: "Santi Béjar" <sbejar@gmail.com>
Cc: hanwen@xs4all.nl, git@vger.kernel.org
Subject: Re: Suggestion: drop 'g' in git-describe suffix
Date: Thu, 02 Nov 2006 13:52:33 +0000	[thread overview]
Message-ID: <4549F821.9090600@shadowen.org> (raw)
In-Reply-To: <8aa486160611020439r255bcdb1q6e7ece46c77de11c@mail.gmail.com>

Santi Béjar wrote:
> On 11/2/06, Andy Whitcroft <apw@shadowen.org> wrote:
>> Santi Béjar wrote:
>> > One problem I see with this scheme (either 'g', 'git' of '+') is that
>> > it does not provide an increasing version number, even for
>> > fast-forwarding commits. Then it is not useful as a package version
>> > number (deb or rpm). I've already seen deb packages with
>> > version+git20061010. One possibility could be to add the number of
>> > commits between the tag and the commit as:
>> >
>> > v1.4.3.3-git12g1e1f76e
>> >
>> > to provide a weak ordering for fast-forwarding commits. What do you
>> thing?
>>
>> I think you'll restart the 1.2.3.4 versioning is better 'debate' again!
> 
> Sorry, I don't undestand this.

There was a long running debate between sha1's and version 'numbers'
1.2.3.4 for each revision.
> 
>> Surly if things are being pushed into a .deb or .rpm we should be using
>> a real release version.  We should be tagging that.  If the project is
>> not providing release number, there is nothing stopping you from tagging
>> them yourself in your copy of the repository and using your tag.  you
>> could use like 'unofficial-N' where N increments in the way you want.
> 
> And where do you store this tag? It is an upstream commit and you just
> refer to this. With the unofficial-N there is no way to know which
> upstream commit you are refering without having access to the git
> repository of the packager  .

Yes that is completly true, but its normally the packer who is doing the
bug fixing of the .deb when its broken.  The key problem is you need
your numbering to be stable.  The only guarenteed stable thing is the
sha1, tags can change.  IMHO you should be including the full sha1 in
the --version output and the package descript, whatever versioning you
are using on the .deb itself.

That said I guess it would be pretty easy to come up with something to
count the number of commits since the last valid tag, something like
that below.  Might not be pretty, nor so easy to turn back into a commit
of course.

-apw

#!/bin/sh

let n=0
git log --pretty=one "$@" | \
        awk '{print $1}' | \
        git name-rev --tags --stdin | \
{
        while read sha1 name
        do
                if [ "$name" != "" ]; then
                        echo "$sha1 $name $n"
                        exit 0
                fi
                let "n=n+1"
        done
        echo "- unknown 0"
        exit 1

  reply	other threads:[~2006-11-02 13:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-02  1:23 Suggestion: drop 'g' in git-describe suffix Han-Wen Nienhuys
2006-11-02  1:47 ` Andy Whitcroft
2006-11-02  9:55   ` Han-Wen Nienhuys
2006-11-02 10:37     ` Andy Whitcroft
2006-11-02 10:53       ` Han-Wen Nienhuys
2006-11-02 10:59         ` Johannes Schindelin
2006-11-02 11:12         ` Santi Béjar
2006-11-02 11:21           ` Andy Whitcroft
2006-11-02 12:39             ` Santi Béjar
2006-11-02 13:52               ` Andy Whitcroft [this message]
2006-11-02 11:23           ` Han-Wen Nienhuys
2006-11-02 12:44             ` Santi Béjar
2006-11-02 14:07             ` Jakub Narebski
2006-11-02 14:48           ` Nicolas Vilz 'niv'
2006-11-02 15:01             ` Johannes Schindelin
2006-11-02 19:12               ` Nicolas Vilz 'niv'
2006-11-02 11:12         ` Andy Whitcroft
2006-11-02 11:03       ` Petr Baudis
2006-11-02 13:45         ` Carl Worth

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=4549F821.9090600@shadowen.org \
    --to=apw@shadowen.org \
    --cc=git@vger.kernel.org \
    --cc=hanwen@xs4all.nl \
    --cc=sbejar@gmail.com \
    /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).