From: Michael J Gruber <git@drmicha.warpmail.net>
To: Joshua Shrader <jshrader83@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: can git-describe learn first-parent behavior?
Date: Tue, 21 Sep 2010 11:34:38 +0200 [thread overview]
Message-ID: <4C987C2E.3060001@drmicha.warpmail.net> (raw)
In-Reply-To: <AANLkTi=6o15y-6Q+tn40=hrPf9pmo+Y1Jd97hGxr5mH2@mail.gmail.com>
Joshua Shrader venit, vidit, dixit 21.09.2010 07:58:
> This seems like it would be a rather useful feature. Suppose a
> maintenance branch, maint/v1.0, is forked from master, and the branch
> point is tagged something like "v1.0-stable". The next commit on
> master is tagged "v2.0-base", indicating that it is the first commit
> of the new release. Suppose two releases are made - a release for
> public consumption of version 1.0, and a release for internal testing
> from master (currently 2.0), and we want to embed the output of
> git-describe into the builds. If bugs were fixed on 1.0, and then 1.0
> was merged into master, it seems perfectly possible to run
> git-describe on master, but get the v1.0 tag in the output.
The earlier tag (in terms of depth) wins, yes.
> Is this just a poor workflow? Am I using git-describe incorrectly?
> Or, does a first-parent option to git-describe seem useful?
>
> Thanks for the input.
If you know you want to describe HEAD based on v2 tags you can use
git describe --match v2\* --tags HEAD
"git describe" does not use the revision walk machinery so that it does
not have the --first-parent option. I'm not sure how useful that is, but
it's easy to implement.
Michael
next prev parent reply other threads:[~2010-09-21 9:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-21 5:58 can git-describe learn first-parent behavior? Joshua Shrader
2010-09-21 9:34 ` Michael J Gruber [this message]
2010-09-21 9:35 ` [RFC PATCH] git-describe: introduce --first-parent Michael J Gruber
2010-09-21 10:03 ` can git-describe learn first-parent behavior? Johannes Sixt
2010-09-21 11:49 ` Michael J Gruber
2010-09-21 12:00 ` Johannes Sixt
2010-09-21 12:10 ` Michael J Gruber
2010-09-21 12:34 ` Johannes Sixt
2010-09-21 15:26 ` Michael J Gruber
2010-09-21 19:57 ` Joshua Shrader
2010-09-22 6:52 ` Michael J Gruber
2010-09-22 17:45 ` Joshua Shrader
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=4C987C2E.3060001@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=jshrader83@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.