All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniele Segato <daniele.segato@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Jeff King <peff@peff.net>, Git Mailing List <git@vger.kernel.org>,
	Marc Branchaud <marcnarc@xiplink.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCHv3] git-tag man: when to use lightweight or annotated tags
Date: Mon, 29 Jul 2013 20:02:07 +0200	[thread overview]
Message-ID: <51F6AE1F.7080607@gmail.com> (raw)
In-Reply-To: <20130726193643.GH14690@google.com>

On 07/26/2013 09:36 PM, Jonathan Nieder wrote:
> Eventually the description section should probably be tweaked to start
> by explaining what the command is actually for. ;-)

Elaborating from this suggestion you gave me I tried to 
rewrite/rearrange the description moving things around a little.

Here's what I've come out with, what do you think about it?



DESCRIPTION
-----------

A tag is a non-mutable reference name (in `refs/tags/`) to an object 
(usually a commit).

If one of `-d/-l/-v` options is given the command will delete, list or 
verify tags.

If one of `-a`, `-s`, or `-u <key-id>` is passed, the command
creates both the reference and a 'tag' object containing a creation 
date, the tagger name and e-mail, a tag message and an optional GnuPG 
signature.  Unless
`-m <msg>` or `-F <file>` is given, an editor is started for the user to 
type in the tag message.

Otherwise just a tag reference for the SHA-1 object name of the commit 
object is created (i.e. a lightweight tag).

Unless `-f` is given, the named tag must not yet exist.

If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
are absent, `-a` is implied.

A GnuPG signed tag object will be created when `-s` or `-u
<key-id>` is used.  When `-u <key-id>` is not used, the
committer identity for the current user is used to find the
GnuPG key for signing.  The configuration variable `gpg.program`
is used to specify custom GnuPG binary.

Tag objects (created with `-a`, `s`, or `-u`) are called "annotated" 
tags; whereas a "lightweight" tag is simply a name for an object 
(usually a commit object).

Annotated tags are meant for release while lightweight tags are meant 
for private or temporary object labels. For this reason, some git 
commands for naming objects (like `git describe`) will ignore 
lightweight tags by default.


--
Cheers,
Daniele Segato

  reply	other threads:[~2013-07-29 18:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-24 10:17 git tag usability issue: Lightweight vs Annotated confusion for the end user (ex. git describe default) Daniele Segato
2013-07-24 20:34 ` Junio C Hamano
2013-07-25 13:45   ` [PATCH] git-tag man: when to use lightweight or annotated tags Daniele Segato
2013-07-25 14:47     ` Marc Branchaud
2013-07-26  8:44       ` Daniele Segato
2013-07-26  8:46         ` Daniele Segato
2013-07-26 14:51           ` Marc Branchaud
2013-07-26 17:19             ` Daniele Segato
2013-07-26 17:33               ` [PATCHv3] " Daniele Segato
2013-07-26 19:06                 ` Jeff King
2013-07-26 19:36                   ` Jonathan Nieder
2013-07-29 18:02                     ` Daniele Segato [this message]
2013-08-07 12:32                       ` Daniele Segato
2013-07-26 21:13                   ` Marc Branchaud
2013-07-29 15:04                     ` Junio C Hamano
2013-07-29 18:20                       ` Daniele Segato
2013-07-27 10:39                   ` Daniele Segato
2013-07-27 11:26                     ` Philip Oakley
2013-07-27 11:45                       ` Stefan Beller
2013-07-29 18:16                         ` Daniele Segato
2013-07-26 21:13               ` [PATCH] " Marc Branchaud
2013-07-29 18:21                 ` Daniele Segato
2013-07-25 13:48   ` git tag usability issue: Lightweight vs Annotated confusion for the end user (ex. git describe default) Daniele Segato

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=51F6AE1F.7080607@gmail.com \
    --to=daniele.segato@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=marcnarc@xiplink.com \
    --cc=peff@peff.net \
    /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.