path: root/Documentation/git-tag.txt
AgeCommit message (Collapse)Author
2021-02-20Documentation: typofix --column descriptionJunio C Hamano
f4ed0af6 (Merge branch 'nd/columns', 2012-05-03) brought in three cut-and-pasted copies of malformatted descriptions. Let's fix them all the same way by marking the configuration variable names up as monospace just like the command line option `--column` is typeset. While we are at it, correct a missing space after the full stop that ends the sentence. Signed-off-by: Junio C Hamano <>
2020-09-18Doc: prefer more specific file nameAaron Lipman
Change filters.txt to ref-reachability-filters.txt in order to avoid squatting on a file name that might be useful for another purpose. Signed-off-by: Aaron Lipman <> Signed-off-by: Junio C Hamano <>
2020-09-16ref-filter: allow merged and no-merged filtersAaron Lipman
Enable ref-filter to process multiple merged and no-merged filters, and extend functionality to git branch, git tag and git for-each-ref. This provides an easy way to check for branches that are "graduation candidates:" $ git branch --no-merged master --merged next If passed more than one merged (or more than one no-merged) filter, refs must be reachable from any one of the merged commits, and reachable from none of the no-merged commits. Signed-off-by: Aaron Lipman <> Signed-off-by: Junio C Hamano <>
2020-09-16Doc: cover multiple contains/no-contains filtersAaron Lipman
Update documentation for "git branch", "git for-each-ref" and "git tag" with notes explaining what happens when passed multiple --contains or --no-contains filters. This behavior is useful to document prior to enabling multiple merged/no-merged filters, in order to demonstrate consistent behavior between merged/no-merged and contains/no-contains filters. Signed-off-by: Aaron Lipman <> Signed-off-by: Junio C Hamano <>
2019-11-07Documentation: fix a bunch of typos, both old and newElijah Newren
Reported-by: Jens Schleusener <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2019-06-05tag: add tag.gpgSign config option to force all tags be GPG-signedTigran Mkrtchyan
As many CI/CD tools don't allow to control command line options when executing `git tag` command, a default value in the configuration file will allow to enforce tag signing if required. The new config-file option tag.gpgSign is added to define default behavior of tag signings. To override default behavior the command line option -s, --sign and --no-sign can be used: $ git tag -m "commit message" will generate a GPG signed tag if tag.gpgSign option is true, while $ git tag --no-sign -m "commit message" will skip the signing step. Signed-off-by: Tigran Mkrtchyan <> Signed-off-by: Junio C Hamano <>
2019-01-23doc: tidy asciidoc styleJean-Noël Avila
This mainly refers to enforcing indentation on additional lines of items of lists. Signed-off-by: Jean-Noël Avila <> Signed-off-by: Junio C Hamano <>
2018-10-23doc: fix descripion for 'git tag --format'Andreas Heiduk
The '--format=<format>' is now listed in the 'OPTIONS' section, not only the '<format>' string itself. The description moved up a few paragraphs because '<format>' is not a standalone paramater but a parameter for the option '--format'. Signed-off-by: Andreas Heiduk <> Signed-off-by: Junio C Hamano <>
2018-08-15Merge branch 'jk/ui-color-always-to-auto'Junio C Hamano
Doc formatting fix. * jk/ui-color-always-to-auto: Documentation: fix --color option formatting
2018-07-18Documentation: fix --color option formattingAndrei Rybak
Add missing colon in two places to fix formatting of options. Signed-off-by: Andrei Rybak <> Signed-off-by: Junio C Hamano <>
2018-05-29tag: clarify in the doc that a tag can refer to a non-commit objectRobert P. J. Day
Reword "man git-tag" to clarify that a tag can refer directly to an arbitrary object, not just a commit object. Signed-off-by: Robert P. J. Day <> Signed-off-by: Junio C Hamano <>
2018-02-07tag: add --edit optionNicolas Morey-Chaisemartin
Add a --edit option whichs allows modifying the messages provided by -m or -F, the same way git commit --edit does. Signed-off-by: Nicolas Morey-Chaisemartin <> Signed-off-by: Junio C Hamano <>
2017-10-04Merge branch 'jk/ui-color-always-to-auto-maint' into jk/ui-color-always-to-autoJunio C Hamano
* jk/ui-color-always-to-auto-maint: color: make "always" the same as "auto" in config provide --color option for all ref-filter users t3205: use --color instead of color.branch=always t3203: drop "always" color test t6006: drop "always" color config tests t7502: use diff.noprefix for --verbose test t7508: use test_terminal for color output t3701: use test-terminal to collect color output t4015: prefer --color to -c color.diff=always test-terminal: set TERM=vt100
2017-10-04provide --color option for all ref-filter usersJeff King
When ref-filter learned about want_color() in 11b087adfd (ref-filter: consult want_color() before emitting colors, 2017-07-13), it became useful to be able to turn colors off and on for specific commands. For git-branch, you can do so with --color/--no-color. But for git-for-each-ref and git-tag, the other users of ref-filter, you have no option except to tweak the "color.ui" config setting. Let's give both of these commands the usual color command-line options. This is a bit more obvious as a method for overriding the config. And it also prepares us for the behavior of "always" changing (so that we are still left with a way of forcing color when our output goes to a non-terminal). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-09-25doc: camelCase the config variables to improve readabilityKaartic Sivaraam
References to multi-word configuration variable names in our documentation must consistently use camelCase to highlight where the word boundaries are, even though these are treated case insensitively. Fix a few places that spell them in all lowercase, which makes them harder to read. Signed-off-by: Kaartic Sivaraam <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2017-09-10Merge branch 'mg/format-ref-doc-fix' into maintJunio C Hamano
Doc fix. * mg/format-ref-doc-fix: Documentation/git-for-each-ref: clarify peeling of tags for --format Documentation: use proper wording for ref format strings
2017-08-18Documentation: use proper wording for ref format stringsMichael J Gruber
Various commands list refs and allow to use a format string for the output that interpolates from the ref as well as the object it points at (for-each-ref; branch and tag in list mode). Currently, the documentation talks about interpolating from the object. This is confusing because a ref points to an object but not vice versa, so the object cannot possible know %(refname), for example. Thus, this is wrong independent of refs being objects (one day, maybe) or not. Change the wording to make this clearer (and distinguish it from formats for the log family). Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2017-08-03tag: change default of `pager.tag` to "on"Martin Ågren
The previous patch taught `git tag` to only respect `pager.tag` in list-mode. That patch left the default value of `pager.tag` at "off". After that patch, it makes sense to let the default value be "on" instead, since it will help with listing many tags, but will not hurt users of `git tag -a` as it would have before. Make that change. Update documentation and tests. Signed-off-by: Martin Ågren <> Signed-off-by: Junio C Hamano <>
2017-08-03tag: respect `pager.tag` in list-mode onlyMartin Ågren
Using, e.g., `git -c pager.tag tag -a new-tag` results in errors such as "Vim: Warning: Output is not to a terminal" and a garbled terminal. Someone who makes use of both `git tag -a` and `git tag -l` will probably not set `pager.tag`, so that `git tag -a` will actually work, at the cost of not paging output of `git tag -l`. Use the mechanisms introduced in two earlier patches to ignore `pager.tag` in git.c and let the `git tag` builtin handle it on its own. Only respect `pager.tag` when running in list-mode. There is a window between where the pager is started before and after this patch. This means that early errors can behave slightly different before and after this patch. Since operation-parsing has to happen inside this window, this can be seen with `git -c pager.tag="echo pager is used" tag -l --unknown-option`. This change in paging-behavior should be acceptable since it only affects erroneous usages. Update the documentation and update tests. If an alias is used to run `git tag -a`, then `pager.tag` will still be respected. Document this known breakage. It will be fixed in a later commit. Add a similar test for `-l`, which works. Noticed-by: Anatoly Borodin <> Suggested-by: Jeff King <> Signed-off-by: Martin Ågren <> Signed-off-by: Junio C Hamano <>
2017-05-23tag: duplicate mention of --contains should mention --no-containsÆvar Arnfjörð Bjarmason
Fix a duplicate mention of --contains in the SYNOPSIS to mention --no-contains. This fixes an error introduced in my commit ac3f5a3468 ("ref-filter: add --no-contains option to tag/branch/for-each-ref", 2017-03-24). Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24ref-filter: reflow recently changed branch/tag/for-each-ref docsÆvar Arnfjörð Bjarmason
Reflow the recently changed branch/tag-for-each-ref documentation. This change shows no changes under --word-diff, except the innocuous change of moving git-tag.txt's "[--sort=<key>]" around slightly. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24ref-filter: add --no-contains option to tag/branch/for-each-refÆvar Arnfjörð Bjarmason
Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. This allows for finding the last-good rollout tag given a known-bad <commit>. Given a hypothetically bad commit cf5c7253e0, the git version to revert to can be found with this hacky two-liner: (git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') | sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10 With this new --no-contains option the same can be achieved with: git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10 As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0: git branch --contains v2.8.0 --no-contains v2.10.0 The "describe" command also has a --contains option, but its semantics are unrelated to what tag/branch/for-each-ref use --contains for. A --no-contains option for "describe" wouldn't make any sense, other than being exactly equivalent to not supplying --contains at all, which would be confusing at best. Add a --without option to "tag" as an alias for --no-contains, for consistency with --with and --contains. The --with option is undocumented, and possibly the only user of it is Junio (<>). But it's trivial to support, so let's do that. The additions to the the test suite are inverse copies of the corresponding --contains tests. With this change --no-contains for tag, branch & for-each-ref is just as well tested as the existing --contains option. In addition to those tests, add a test for "tag" which asserts that --no-contains won't find tree/blob tags, which is slightly unintuitive, but consistent with how --contains works & is documented. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24tag: change --point-at to default to HEADÆvar Arnfjörð Bjarmason
Change the --points-at option to default to HEAD for consistency with its siblings --contains, --merged etc. which default to HEAD. Previously we'd get: $ git tag --points-at 2>&1 | head -n 1 error: option `points-at' requires a value This changes behavior added in commit ae7706b9ac (tag: add --points-at list option, 2012-02-08). Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24tag: implicitly supply --list given another list-like optionÆvar Arnfjörð Bjarmason
Change the "tag" command to implicitly turn on its --list mode when provided with a list-like option such as --contains, --points-at etc. This is for consistency with how "branch" works. When "branch" is given a list-like option, such as --contains, it implicitly provides --list. Before this change "tag" would error out on those sorts of invocations. I.e. while both of these worked for "branch": git branch --contains v2.8.0 <pattern> git branch --list --contains v2.8.0 <pattern> Only the latter form worked for "tag": git tag --contains v2.8.0 '*rc*' git tag --list --contains v2.8.0 '*rc*' Now "tag", like "branch", will implicitly supply --list when a list-like option is provided, and no other conflicting non-list options (such as -d) are present on the command-line. Spelunking through the history via: git log --reverse -p -G'only allowed with' -- '*builtin*tag*c' Reveals that there was no good reason for not allowing this in the first place. The --contains option added in 32c35cfb1e ("git-tag: Add --contains option", 2009-01-26) made this an error. All the other subsequent list-like options that were added copied its pattern of making this usage an error. The only tests that break as a result of this change are tests that were explicitly checking that this "branch-like" usage wasn't permitted. Change those failing tests to check that this invocation mode is permitted, add extra tests for the list-like options we weren't testing, and tests to ensure that e.g. we don't toggle the list mode in the presence of other conflicting non-list options. With this change errors messages such as "--contains option is only allowed with -l" don't make sense anymore, since options like --contain turn on -l. Instead we error out when list-like options such as --contain are used in conjunction with conflicting options such as -d or -v. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24tag: change misleading --list <pattern> documentationÆvar Arnfjörð Bjarmason
Change the documentation for --list so that it's described as a toggle, not as an option that takes a <pattern> as an argument. Junio initially documented this in b867c7c23a ("git-tag: -l to list tags (usability).", 2006-02-17), but later Jeff King changed "tag" to accept multiple patterns in 588d0e834b ("tag: accept multiple patterns for --list", 2011-06-20). However, documenting this as "-l <pattern>" was never correct, as these both worked before Jeff's change: git tag -l 'v*' git tag 'v*' -l One would expect an option that was documented like that to only accept: git tag --list git tag --list 'v*rc*' And after Jeff's change, one that took multiple patterns: git tag --list 'v*rc*' --list '*2.8*' But since it's actually a toggle all of these work as well, and produce identical output to the last example above: git tag --list 'v*rc*' '*2.8*' git tag --list 'v*rc*' '*2.8*' --list --list --list git tag --list 'v*rc*' '*2.8*' --list -l --list -l --list Now the documentation is more in tune with how the "branch" command describes its --list option since commit cddd127b9a ("branch: introduce --list option", 2011-08-28). Change the test suite to assert that these invocations work for the cases that weren't already being tested for. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-21ref-filter: make combining --merged & --no-merged an errorÆvar Arnfjörð Bjarmason
Change the behavior of specifying --merged & --no-merged to be an error, instead of silently picking the option that was provided last. Subsequent changes of mine add a --no-contains option in addition to the existing --contains. Providing both of those isn't an error, and has actual meaning. Making its cousins have different behavior in this regard would be confusing to the user, especially since we'd be silently disregarding some of their command-line input. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-21tag doc: reword --[no-]merged to talk about commits, not tipsÆvar Arnfjörð Bjarmason
Change the wording for the --merged and --no-merged options to talk about "commits" instead of "tips". This phrasing was copied from the "branch" documentation in commit 5242860f54 ("tag.c: implement '--merged' and '--no-merged' options", 2015-09-10). Talking about the "tip" is branch nomenclature, not something usually associated with tags. This phrasing might lead the reader to believe that these options might find tags pointing to trees or blobs, let's instead be explicit and only talk about commits. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-21tag doc: split up the --[no-]merged documentationÆvar Arnfjörð Bjarmason
Split up the --[no-]merged documentation into documentation that documents each option independently. This is in line with how "branch" and "for-each-ref" are documented, and makes subsequent changes to discuss the limits & caveats of each option easier to read. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-21tag doc: move the description of --[no-]merged earlierÆvar Arnfjörð Bjarmason
Move the documentation for the --merged & --no-merged options earlier in the documentation, to sit along the other switches, and right next to the similar --contains and --points-at switches. It makes more sense to group the options together, not have some options after the like of <tagname>, <object>, <format> etc. This was originally put there when the --merged & --no-merged options were introduced in 5242860f54 ("tag.c: implement '--merged' and '--no-merged' options", 2015-09-10). It's not apparent from that commit that the documentation is being placed apart from other options, rather than along with them, so this was likely missed in the initial review. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-02-03Merge branch 'cw/log-updates-for-all-refs-really'Junio C Hamano
The "core.logAllRefUpdates" that used to be boolean has been enhanced to take 'always' as well, to record ref updates to refs other than the ones that are expected to be updated (i.e. branches, remote-tracking branches and notes). * cw/log-updates-for-all-refs-really: doc: add note about ignoring '--no-create-reflog' update-ref: add test cases for bare repository refs: add option core.logAllRefUpdates = always config: add markup to core.logAllRefUpdates doc
2017-02-01doc: add note about ignoring '--no-create-reflog'Cornelius Weig
The commands git-branch and git-tag accept the '--create-reflog' option, and create reflog even when core.logallrefupdates configuration is explicitly set not to. On the other hand, the negated form '--no-create-reflog' is accepted as a valid option but has no effect (other than overriding an earlier '--create-reflog' on the command line). This silent noop may puzzle users. To communicate that this is a known limitation, add a short note in the manuals for git-branch and git-tag. Signed-off-by: Cornelius Weig <> Helped-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-01-31Merge branch 'st/verify-tag'Junio C Hamano
"git tag" and "git verify-tag" learned to put GPG verification status in their "--format=<placeholders>" output format. * st/verify-tag: t/t7004-tag: Add --format specifier tests t/t7030-verify-tag: Add --format specifier tests builtin/tag: add --format argument for tag -v builtin/verify-tag: add --format to verify-tag ref-filter: add function to print single ref_array_item gpg-interface, tag: add GPG_VERIFY_OMIT_STATUS flag
2017-01-31refs: add option core.logAllRefUpdates = alwaysCornelius Weig
When core.logallrefupdates is true, we only create a new reflog for refs that are under certain well-known hierarchies. The reason is that we know that some hierarchies (like refs/tags) are not meant to change, and that unknown hierarchies might not want reflogs at all (e.g., a hypothetical refs/foo might be meant to change often and drop old history immediately). However, sometimes it is useful to override this decision and simply log for all refs, because the safety and audit trail is more important than the performance implications of keeping the log around. This patch introduces a new "always" mode for the core.logallrefupdates option which will log updates to everything under refs/, regardless where in the hierarchy it is (we still will not log things like ORIG_HEAD and FETCH_HEAD, which are known to be transient). Based-on-patch-by: Jeff King <> Signed-off-by: Cornelius Weig <> Reviewed-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-01-23Merge branch 'sg/fix-versioncmp-with-common-suffix'Junio C Hamano
The prereleaseSuffix feature of version comparison that is used in "git tag -l" did not correctly when two or more prereleases for the same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2 are there and the code needs to compare 2.0-beta1 and 2.0-beta2). * sg/fix-versioncmp-with-common-suffix: versioncmp: generalize version sort suffix reordering versioncmp: factor out helper for suffix matching versioncmp: use earliest-longest contained suffix to determine sorting order versioncmp: cope with common part overlapping with prerelease suffix versioncmp: pass full tagnames to swap_prereleases() t7004-tag: add version sort tests to show prerelease reordering issues t7004-tag: use test_config helper t7004-tag: delete unnecessary tags with test_when_finished
2017-01-18builtin/tag: add --format argument for tag -vLukas Puehringer
Adding --format to git tag -v mutes the default output of the GPG verification and instead prints the formatted tag object. This allows callers to cross-check the tagname from refs/tags with the tagname from the tag object header upon GPG verification. The callback function for for_each_tag_name() didn't allow callers to pass custom data to their callback functions. Add a new opaque pointer to each_tag_name_fn's parameter to allow this. Signed-off-by: Lukas Puehringer <> Signed-off-by: Junio C Hamano <>
2017-01-12versioncmp: generalize version sort suffix reorderingSZEDER Gábor
The 'versionsort.prereleaseSuffix' configuration variable, as its name suggests, is supposed to only deal with tagnames with prerelease suffixes, and allows sorting those prerelease tags in a user-defined order before the suffixless main release tag, instead of sorting them simply lexicographically. However, the previous changes in this series resulted in an interesting and useful property of version sort: - The empty string as a configured suffix matches all tagnames, including tagnames without any suffix, but - tagnames containing a "real" configured suffix are still ordered according to that real suffix, because any longer suffix takes precedence over the empty string. Exploiting this property we can easily generalize suffix reordering and specify the order of tags with given suffixes not only before but even after a main release tag by using the empty suffix to denote the position of the main release tag, without any algorithm changes: $ git -c versionsort.prereleaseSuffix=-alpha \ -c versionsort.prereleaseSuffix=-beta \ -c versionsort.prereleaseSuffix="" \ -c versionsort.prereleaseSuffix=-gamma \ -c versionsort.prereleaseSuffix=-delta \ tag -l --sort=version:refname 'v3.0*' v3.0-alpha1 v3.0-beta1 v3.0 v3.0-gamma1 v3.0-delta1 Since 'versionsort.prereleaseSuffix' is not a fitting name for a configuration variable to control this more general suffix reordering, introduce the new variable 'versionsort.suffix'. Still keep the old configuration variable name as a deprecated alias, though, to avoid suddenly breaking setups already using it. Ignore the old variable if both old and new configuration variables are set, but emit a warning so users will be aware of it and can fix their configuration. Extend the documentation to describe and add a test to check this more general behavior. Note: since the empty suffix matches all tagnames, tagnames with suffixes not included in the configuration are listed together with the suffixless main release tag, ordered lexicographically right after that, i.e. before tags with suffixes listed in the configuration following the empty suffix. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2016-12-05tag, branch, for-each-ref: add --ignore-case for sorting and filteringNguyễn Thái Ngọc Duy
This options makes sorting ignore case, which is great when you have branches named bug-12-do-something, Bug-12-do-some-more and BUG-12-do-what and want to group them together. Sorting externally may not be an option because we lose coloring and column layout from git-branch and git-tag. The same could be said for filtering, but it's probably less important because you can always go with the ugly pattern [bB][uU][gG]-* if you're desperate. You can't have case-sensitive filtering and case-insensitive sorting (or the other way around) with this though. For branch and tag, that should be no problem. for-each-ref, as a plumbing, might want finer control. But we can always add --{filter,sort}-ignore-case when there is a need for it. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2016-10-26Merge branch 'yk/git-tag-remove-mention-of-old-layout-in-doc'Junio C Hamano
Shorten description of auto-following in "git tag" by removing a mention of historical remotes layout which is not relevant to the main topic. * yk/git-tag-remove-mention-of-old-layout-in-doc: doc: remove reference to the traditional layout in git-tag.txt
2016-10-20doc: remove reference to the traditional layout in git-tag.txtYounes Khoudli
This is the only place in the documentation that the traditional layout is mentioned, and it is confusing. Remove it. * Documentation/git-tag.txt: Here. Signed-off-by: Younes Khoudli <> Signed-off-by: Junio C Hamano <>
2016-07-13Merge branch 'mm/doc-tt'Junio C Hamano
More mark-up updates to typeset strings that are expected to literally typed by the end user in fixed-width font. * mm/doc-tt: doc: typeset HEAD and variants as literal CodingGuidelines: formatting HEAD in documentation doc: typeset long options with argument as literal doc: typeset '--' as literal doc: typeset long command-line options as literal doc: typeset short command-line options as literal Documentation/git-mv.txt: fix whitespace indentation
2016-06-28doc: typeset HEAD and variants as literalMatthieu Moy
This is an application of the newly added CodingGuidelines to HEAD and variants like FETCH_HEAD. It was obtained with: perl -pi -e "s/'([A-Z_]*HEAD)'/\`\$1\`/g" *.txt Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2016-06-28doc: typeset long command-line options as literalMatthieu Moy
Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2016-06-27Merge branch 'dn/gpg-doc'Junio C Hamano
The documentation tries to consistently spell "GPG"; when referring to the specific program name, "gpg" is used. * dn/gpg-doc: Documentation: GPG capitalization
2016-06-17Documentation: GPG capitalizationDave Nicolson
When "GPG" is used in a sentence it is now consistently capitalized. When referring to the binary it is left as "gpg". Signed-off-by: David Nicolson <> Signed-off-by: Junio C Hamano <>
2016-06-08doc: change configuration variables formatTom Russello
This change configuration variables that where in italic style to monospace font according to the guideline. It was obtained with grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \ sed -e 's/::$//' -e 's/\./\\\\./' | \ xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt Signed-off-by: Tom Russello <> Signed-off-by: Erwan Mathoniere <> Signed-off-by: Samuel Groot <> Signed-off-by: Matthieu Moy <> Reviewed-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2016-01-26tag: do not show ambiguous tag names as "tags/foo"Jeff King
Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11), git-tag has started showing tags with ambiguous names (i.e., when both "heads/foo" and "tags/foo" exists) as "tags/foo" instead of just "foo". This is both: - pointless; the output of "git tag" includes only refs/tags, so we know that "foo" means the one in "refs/tags". and - ambiguous; in the original output, we know that the line "foo" means that "refs/tags/foo" exists. In the new output, it is unclear whether we mean "refs/tags/foo" or "refs/tags/tags/foo". The reason this happens is that commit b7cc53e9 switched git-tag to use ref-filter's "%(refname:short)" output formatting, which was adapted from for-each-ref. This more general code does not know that we care only about tags, and uses shorten_unambiguous_ref to get the short-name. We need to tell it that we care only about "refs/tags/", and it should shorten with respect to that value. In theory, the ref-filter code could figure this out by us passing FILTER_REFS_TAGS. But there are two complications there: 1. The handling of refname:short is deep in formatting code that does not even have our ref_filter struct, let alone the arguments to the filter_ref struct. 2. In git v2.7.0, we expose the formatting language to the user. If we follow this path, it will mean that "%(refname:short)" behaves differently for "tag" versus "for-each-ref" (including "for-each-ref refs/tags/"), which can lead to confusion. Instead, let's add a new modifier to the formatting language, "strip", to remove a specific set of prefix components. This fixes "git tag", and lets users invoke the same behavior from their own custom formats (for "tag" or "for-each-ref") while leaving ":short" with its same consistent meaning in all places. We introduce a test in t7004 for "git tag", which fails without this patch. We also add a similar test in t3203 for "git branch", which does not actually fail. But since it is likely that "branch" will eventually use the same formatting code, the test helps defend against future regressions. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-10-05Merge branch 'mm/keyid-docs'Junio C Hamano
Very small number of options take a parameter that is optional (which is not a great UI element as they can only appear at the end of the command line). Add notice to documentation of each and every one of them. * mm/keyid-docs: Documentation: explain optional arguments better Documentation/grep: fix documentation of -O Documentation: use 'keyid' consistently, not 'key-id'
2015-09-21Documentation: use 'keyid' consistently, not 'key-id'Matthieu Moy
Signed-off-by: Matthieu Moy <> Reviewed-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-09-17tag.c: implement '--merged' and '--no-merged' optionsKarthik Nayak
Use 'ref-filter' APIs to implement the '--merged' and '--no-merged' options into 'tag.c'. The '--merged' option lets the user to only list tags merged into the named commit. The '--no-merged' option lets the user to only list tags not merged into the named commit. If no object is provided it assumes HEAD as the object. Add documentation and tests for the same. Mentored-by: Christian Couder <> Mentored-by: Matthieu Moy <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>
2015-09-17tag.c: implement '--format' optionKarthik Nayak
Implement the '--format' option provided by 'ref-filter'. This lets the user list tags as per desired format similar to the implementation in 'git for-each-ref'. Add tests and documentation for the same. Mentored-by: Christian Couder <> Mentored-by: Matthieu Moy <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>