path: root/builtin/tag.c
AgeCommit message (Collapse)Author
2017-06-24Merge branch 'bw/config-h'Junio C Hamano
Fix configuration codepath to pay proper attention to commondir that is used in multi-worktree situation, and isolate config API into its own header file. * bw/config-h: config: don't implicitly use gitdir or commondir config: respect commondir setup: teach discover_git_directory to respect the commondir config: don't include config.h by default config: remove git_config_iter config: create config.h
2017-06-15config: don't include config.h by defaultBrandon Williams
Stop including config.h by default in cache.h. Instead only include config.h in those files which require use of the config system. Signed-off-by: Brandon Williams <> Signed-off-by: Junio C Hamano <>
2017-05-29Merge branch 'bc/object-id'Junio C Hamano
Conversion from uchar[20] to struct object_id continues. * bc/object-id: (53 commits) object: convert parse_object* to take struct object_id tree: convert parse_tree_indirect to struct object_id sequencer: convert do_recursive_merge to struct object_id diff-lib: convert do_diff_cache to struct object_id builtin/ls-tree: convert to struct object_id merge: convert checkout_fast_forward to struct object_id sequencer: convert fast_forward_to to struct object_id builtin/ls-files: convert overlay_tree_on_cache to object_id builtin/read-tree: convert to struct object_id sha1_name: convert internals of peel_onion to object_id upload-pack: convert remaining parse_object callers to object_id revision: convert remaining parse_object callers to object_id revision: rename add_pending_sha1 to add_pending_oid http-push: convert process_ls_object and descendants to object_id refs/files-backend: convert many internals to struct object_id refs: convert struct ref_update to use struct object_id ref-filter: convert some static functions to struct object_id Convert struct ref_array_item to struct object_id Convert the verify_pack callback to struct object_id Convert lookup_tag to struct object_id ...
2017-05-08Convert lookup_commit* to struct object_idbrian m. carlson
Convert lookup_commit, lookup_commit_or_die, lookup_commit_reference, and lookup_commit_reference_gently to take struct object_id arguments. Introduce a temporary in parse_object buffer in order to convert this function. This is required since in order to convert parse_object and parse_object_buffer, lookup_commit_reference_gently and lookup_commit_or_die would need to be converted. Not introducing a temporary would therefore require that lookup_commit_or_die take a struct object_id *, but lookup_commit would take unsigned char *, leaving a confusing and hard-to-use interface. parse_object_buffer will lose this temporary in a later patch. This commit was created with manual changes to commit.c, commit.h, and object.c, plus the following semantic patch: @@ expression E1, E2; @@ - lookup_commit_reference_gently(E1.hash, E2) + lookup_commit_reference_gently(&E1, E2) @@ expression E1, E2; @@ - lookup_commit_reference_gently(E1->hash, E2) + lookup_commit_reference_gently(E1, E2) @@ expression E1; @@ - lookup_commit_reference(E1.hash) + lookup_commit_reference(&E1) @@ expression E1; @@ - lookup_commit_reference(E1->hash) + lookup_commit_reference(E1) @@ expression E1; @@ - lookup_commit(E1.hash) + lookup_commit(&E1) @@ expression E1; @@ - lookup_commit(E1->hash) + lookup_commit(E1) @@ expression E1, E2; @@ - lookup_commit_or_die(E1.hash, E2) + lookup_commit_or_die(&E1, E2) @@ expression E1, E2; @@ - lookup_commit_or_die(E1->hash, E2) + lookup_commit_or_die(E1, E2) Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2017-05-08builtin/tag: convert to struct object_idbrian m. carlson
Parts of this module call lookup_commit_reference, which we want to convert. The module is small and mostly self-contained, so convert the rest of it while we're at it. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2017-05-01i18n: remove i18n from tag reflog messageJean-Noel Avila
The building of the reflog message is using strbuf, which is not friendly with internationalization frameworks. No other reflog messages are translated right now and switching all the messages to i18n would require a major rework of the way the messages are built. Signed-off-by: Jean-Noel Avila <> Signed-off-by: Junio C Hamano <>
2017-04-17Merge branch 'jk/snprintf-cleanups'Junio C Hamano
Code clean-up. * jk/snprintf-cleanups: daemon: use an argv_array to exec children gc: replace local buffer with git_path transport-helper: replace checked snprintf with xsnprintf convert unchecked snprintf into xsnprintf combine-diff: replace malloc/snprintf with xstrfmt replace unchecked snprintf calls with heap buffers receive-pack: print --pack-header directly into argv array name-rev: replace static buffer with strbuf create_branch: use xstrfmt for reflog message create_branch: move msg setup closer to point of use avoid using mksnpath for refs avoid using fixed PATH_MAX buffers for refs fetch: use heap buffer to format reflog tag: use strbuf to format tag header diff: avoid fixed-size buffer for patch-ids odb_mkstemp: use git_path_buf odb_mkstemp: write filename into strbuf do not check odb_mkstemp return value for errors
2017-03-30avoid using fixed PATH_MAX buffers for refsJeff King
Many functions which handle refs use a PATH_MAX-sized buffer to do so. This is mostly reasonable as we have to write loose refs into the filesystem, and at least on Linux the 4K PATH_MAX is big enough that nobody would care. But: 1. The static PATH_MAX is not always the filesystem limit. 2. On other platforms, PATH_MAX may be much smaller. 3. As we move to alternate ref storage, we won't be bound by filesystem limits. Let's convert these to heap buffers so we don't have to worry about truncation or size limits. We may want to eventually constrain ref lengths for sanity and to prevent malicious names, but we should do so consistently across all platforms, and in a central place (like the ref code). Signed-off-by: Jeff King <>
2017-03-30tag: use strbuf to format tag headerJeff King
We format the tag header into a fixed 1024-byte buffer. But since the tag-name and tagger ident can be arbitrarily large, we may unceremoniously die with "tag header too big". Let's just use a strbuf instead. Note that it looks at first glance like we can just format this directly into the "buf" strbuf where it will ultimately go. But that buffer may already contain the tag message, and we have no easy way to prepend formatted data to a strbuf (we can only splice in an already-generated buffer). This isn't a performance-critical path, so going through an extra buffer isn't a big deal. Signed-off-by: Jeff King <>
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-02-27Merge branch 'km/delete-ref-reflog-message'Junio C Hamano
"git update-ref -d" and other operations to delete references did not leave any entry in HEAD's reflog when the reference being deleted was the current branch. This is not a problem in practice because you do not want to delete the branch you are currently on, but caused renaming of the current branch to something else not to be logged in a useful way. * km/delete-ref-reflog-message: branch: record creation of renamed branch in HEAD's log rename_ref: replace empty message in HEAD's log update-ref: pass reflog message to delete_ref() delete_ref: accept a reflog message argument
2017-02-27Merge branch 'cw/tag-reflog-message'Junio C Hamano
"git tag" did not leave useful message when adding a new entry to reflog; this was left unnoticed for a long time because refs/tags/* doesn't keep reflog by default. * cw/tag-reflog-message: tag: generate useful reflog message
2017-02-27Merge branch 'kn/ref-filter-branch-list'Junio C Hamano
The code to list branches in "git branch" has been consolidated with the more generic ref-filter API. * kn/ref-filter-branch-list: (21 commits) ref-filter: resurrect "strip" as a synonym to "lstrip" branch: implement '--format' option branch: use ref-filter printing APIs branch, tag: use porcelain output ref-filter: allow porcelain to translate messages in the output ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>' ref-filter: Do not abruptly die when using the 'lstrip=<N>' option ref-filter: rename the 'strip' option to 'lstrip' ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal() ref-filter: introduce refname_atom_parser() ref-filter: introduce refname_atom_parser_internal() ref-filter: make "%(symref)" atom work with the ':short' modifier ref-filter: add support for %(upstream:track,nobracket) ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams ref-filter: introduce format_ref_array_item() ref-filter: move get_head_description() from branch.c ref-filter: modify "%(objectname:short)" to take length ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>) ref-filter: include reference to 'used_atom' within 'atom_value' ...
2017-02-21delete_ref: accept a reflog message argumentKyle Meyer
When the current branch is renamed with 'git branch -m/-M' or deleted with 'git update-ref -m<msg> -d', the event is recorded in HEAD's log with an empty message. In preparation for adding a more meaningful message to HEAD's log in these cases, update delete_ref() to take a message argument and pass it along to ref_transaction_delete(). Modify all callers to pass NULL for the new message argument; no change in behavior is intended. Note that this is relevant for HEAD's log but not for the deleted ref's log, which is currently deleted along with the ref. Even if it were not, an entry for the deletion wouldn't be present in the deleted ref's log. files_transaction_commit() writes to the log if REF_NEEDS_COMMIT or REF_LOG_ONLY are set, but lock_ref_for_update() doesn't set REF_NEEDS_COMMIT for the deleted ref because REF_DELETING is set. In contrast, the update for HEAD has REF_LOG_ONLY set by split_head_update(), resulting in the deletion being logged. Signed-off-by: Kyle Meyer <> Signed-off-by: Junio C Hamano <>
2017-02-08tag: generate useful reflog messageCornelius Weig
When tags are created with `--create-reflog` or with the option `core.logAllRefUpdates` set to 'always', a reflog is created for them. So far, the description of reflog entries for tags was empty, making the reflog hard to understand. For example: 6e3a7b3 refs/tags/test@{0}: Now, a reflog message is generated when creating a tag, following the pattern "tag: tagging <short-sha1> (<description>)". If GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION (<description>)" instead. If the tag references a commit object, the description is set to the subject line of the commit, followed by its commit date. For example: 6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03) If the tag points to a tree/blob/tag objects, the following static strings are taken as description: - "tree object" - "blob object" - "other tag object" Signed-off-by: Cornelius Weig <> 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-31branch, tag: use porcelain outputKarthik Nayak
Call ref-filter's setup_ref_filter_porcelain_msg() to enable translated messages for the %(upstream:tack) atom. Although branch.c doesn't currently use ref-filter's printing API's, this will ensure that when it does in the future patches, we do not need to worry about translation. Written-by: Matthieu Moy <> Mentored-by: Christian Couder <> Mentored-by: Matthieu Moy <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>
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-10ref-filter: rename the 'strip' option to 'lstrip'Karthik Nayak
In preparation for the upcoming patch, where we introduce the 'rstrip' option. Rename the 'strip' option to 'lstrip' to remove ambiguity. Signed-off-by: Karthik Nayak <> 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-04-29Merge branch 'st/verify-tag'Junio C Hamano
Unify internal logic between "git tag -v" and "git verify-tag" commands by making one directly call into the other. * st/verify-tag: tag -v: verify directly rather than exec-ing verify-tag verify-tag: move tag verification code to tag.c verify-tag: prepare verify_tag for libification verify-tag: update variable name and type t7030: test verifying multiple tags builtin/verify-tag.c: ignore SIGPIPE in gpg-interface
2016-04-22tag -v: verify directly rather than exec-ing verify-tagSantiago Torres
Instead of having tag -v fork to run verify-tag, use the gpg_verify_tag() function directly. Helped-by: Eric Sunshine <> Signed-off-by: Santiago Torres <> Reviewed-by: Eric Sunshine <> Signed-off-by: Junio C Hamano <>
2016-03-22tag: add the option to force signing of annotated tagsLaurent Arnoud
The `tag.forcesignannotated` configuration variable makes "git tag" that would implicitly create an annotated tag to instead create a signed tag. For example $ git tag -m "This is a message" tag-with-message $ git tag -F message-file tag-with-message would create a signed tag if the configuration variable is in effect. To override this from the command line, the user can explicitly ask for an annotated tag, like so: $ git tag -a -m "This is a message" tag-with-message $ git tag -a -F message-file tag-with-message Creation of a light-weight tag, i.e. $ git tag lightweight is not affected. Signed-off-by: Laurent Arnoud <> 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-26Merge branch 'kn/for-each-tag'Junio C Hamano
Recent update to "git tag --contains" caused a performance regression. * kn/for-each-tag: tag.c: use the correct algorithm for the '--contains' option
2015-10-26Merge branch 'tk/stripspace'Junio C Hamano
The internal stripspace() function has been moved to where it logically belongs to, i.e. strbuf API, and the command line parser of "git stripspace" has been updated to use the parse_options API. * tk/stripspace: stripspace: use parse-options for command-line parsing strbuf: make stripspace() part of strbuf
2015-10-18tag.c: use the correct algorithm for the '--contains' optionKarthik Nayak
In b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-09-11) we port tag.c to use the ref-filter APIs for filtering and printing refs. In ref-filter we have two implementations for filtering refs when the '--contains' option is used. Although they do the same thing, one is optimized for filtering branches and the other for tags (borrowed from branch.c and tag.c respectively) and the 'filter->with_commit_tag_algo' bit decides which algorithm must be used. We should unify these. When we ported tag.c to use ref-filter APIs we missed out on setting the 'filter->with_commit_tag_algo' bit. As reported by Jerry Snitselaar, this causes "git tag --contains" to work way slower than expected, fix this by setting 'filter->with_commit_tag_algo' in tag.c before calling 'filter_refs()'. Mentored-by: Matthieu Moy <> Tested-by: Jerry Snitselaar <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>
2015-10-16strbuf: make stripspace() part of strbufTobias Klauser
This function is also used in other builtins than stripspace, so it makes sense to have it in a more generic place. Since it operates on an strbuf and the function is declared in strbuf.h, move it to strbuf.c and add the corresponding prefix to its name, just like other API functions in the strbuf_* family. Also switch all current users of stripspace() to the new function name and keep a temporary wrapper inline function for any topic branches still using stripspace(). Reviewed-by: Matthieu Moy <> Signed-off-by: Tobias Klauser <> Signed-off-by: Junio C Hamano <>
2015-10-05Merge branch 'kn/for-each-tag'Junio C Hamano
The "ref-filter" code was taught about many parts of what "tag -l" does and then "tag -l" is being reimplemented in terms of "ref-filter". * kn/for-each-tag: tag.c: implement '--merged' and '--no-merged' options tag.c: implement '--format' option tag.c: use 'ref-filter' APIs tag.c: use 'ref-filter' data structures ref-filter: add option to match literal pattern ref-filter: add support to sort by version ref-filter: add support for %(contents:lines=X) ref-filter: add option to filter out tags, branches and remotes ref-filter: implement an `align` atom ref-filter: introduce match_atom_name() ref-filter: introduce handler function for each atom utf8: add function to align a string into given strbuf ref-filter: introduce ref_formatting_state and ref_formatting_stack ref-filter: move `struct atom_value` to ref-filter.c strtoul_ui: reject negative values
2015-10-05Merge branch 'kn/for-each-tag-branch'Junio C Hamano
Some features from "git tag -l" and "git branch -l" have been made available to "git for-each-ref" so that eventually the unified implementation can be shared across all three, in a follow-up series or two. * kn/for-each-tag-branch: for-each-ref: add '--contains' option ref-filter: implement '--contains' option parse-options.h: add macros for '--contains' option parse-option: rename parse_opt_with_commit() for-each-ref: add '--merged' and '--no-merged' options ref-filter: implement '--merged' and '--no-merged' options ref-filter: add parse_opt_merge_filter() for-each-ref: add '--points-at' option ref-filter: implement '--points-at' option tag: libify parse_opt_points_at() t6302: for-each-ref tests for ref-filter APIs
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 <>
2015-09-17tag.c: use 'ref-filter' APIsKarthik Nayak
Make 'tag.c' use 'ref-filter' APIs for iterating through refs, sorting and printing of refs. This removes most of the code used in 'tag.c' replacing it with calls to the 'ref-filter' library. Make 'tag.c' use the 'filter_refs()' function provided by 'ref-filter' to filter out tags based on the options set. For printing tags we use 'show_ref_array_item()' function provided by 'ref-filter'. We improve the sorting option provided by 'tag.c' by using the sorting options provided by 'ref-filter'. This causes the test 'invalid sort parameter on command line' in t7004 to fail, as 'ref-filter' throws an error for all sorting fields which are incorrect. The test is changed to reflect the same. Modify documentation 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: use 'ref-filter' data structuresKarthik Nayak
Make 'tag.c' use 'ref-filter' data structures and make changes to support the new data structures. This is a part of the process of porting 'tag.c' to use 'ref-filter' APIs. This is a temporary step before porting 'tag.c' to use 'ref-filter' completely. As this is a temporary step, most of the code introduced here will be removed when 'tag.c' is ported over to use 'ref-filter' APIs. Mentored-by: Christian Couder <> Mentored-by: Matthieu Moy <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>
2015-09-17ref-filter: add support for %(contents:lines=X)Karthik Nayak
In 'tag.c' we can print N lines from the annotation of the tag using the '-n<num>' option. Copy code from 'tag.c' to 'ref-filter' and modify it to support appending of N lines from the annotation of tags to the given strbuf. Implement %(contents:lines=X) where X lines of the given object are obtained. While we're at it, remove unused "contents:<suboption>" atoms from the `valid_atom` array. Add documentation and test for the same. Mentored-by: Christian Couder <> Mentored-by: Matthieu Moy <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>
2015-09-11tag, update-ref: improve description of option "create-reflog"Ralf Thielow
The description of option "create-reflog" is "create_reflog", which is neither a good description, nor a sensible string to translate. Change it to a more meaningful message. Signed-off-by: Ralf Thielow <> Signed-off-by: Junio C Hamano <>
2015-08-24Merge 'kn/for-each-tag-branch' into kn/for-each-tagJunio C Hamano
* kn/for-each-tag-branch: for-each-ref: add '--contains' option ref-filter: implement '--contains' option parse-options.h: add macros for '--contains' option parse-option: rename parse_opt_with_commit() for-each-ref: add '--merged' and '--no-merged' options ref-filter: implement '--merged' and '--no-merged' options ref-filter: add parse_opt_merge_filter() for-each-ref: add '--points-at' option ref-filter: implement '--points-at' option tag: libify parse_opt_points_at() t6302: for-each-ref tests for ref-filter APIs
2015-08-03ref-filter: implement '--contains' optionKarthik Nayak
'tag -l' and 'branch -l' have two different ways of finding out if a certain ref contains a commit. Implement both these methods in ref-filter and give the caller of ref-filter API the option to pick which implementation to be used. 'branch -l' uses 'is_descendant_of()' from commit.c which is left as the default implementation to be used. 'tag -l' uses a more specific algorithm since ffc4b80. This implementation is used whenever the 'with_commit_tag_algo' bit is set in 'struct ref_filter'. Mentored-by: Christian Couder <> Mentored-by: Matthieu Moy <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>
2015-08-03parse-options.h: add macros for '--contains' optionKarthik Nayak
Add a macro for using the '--contains' option in parse-options.h also include an optional '--with' option macro which performs the same action as '--contains'. Make tag.c and branch.c use this new macro. Mentored-by: Christian Couder <> Mentored-by: Matthieu Moy <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>
2015-08-03parse-option: rename parse_opt_with_commit()Karthik Nayak
Rename parse_opt_with_commit() to parse_opt_commits() to show that it can be used to obtain a list of commits and is not constricted to usage of '--contains' option. Mentored-by: Christian Couder <> Mentored-by: Matthieu Moy <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>
2015-08-03ref-filter: implement '--points-at' optionKarthik Nayak
In 'tag -l' we have '--points-at' option which lets users list only tags of a given object. Implement this option in 'ref-filter.{c,h}' so that other commands can benefit from this. This is duplicated from tag.c, we will eventually remove that when we port tag.c to use ref-filter APIs. Based-on-patch-by: Jeff King <> Mentored-by: Christian Couder <> Mentored-by: Matthieu Moy <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>
2015-08-03tag: libify parse_opt_points_at()Karthik Nayak
Rename 'parse_opt_points_at()' to 'parse_opt_object_name()' and move it from 'tag.c' to 'parse-options'. This now acts as a common parse_opt function which accepts an objectname and stores it into a sha1_array. Based-on-patch-by: Jeff King <> Mentored-by: Christian Couder <> Mentored-by: Matthieu Moy <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>
2015-07-21update-ref and tag: add --create-reflog argDavid Turner
Allow the creation of a ref (e.g. stash) with a reflog already in place. For most refs (e.g. those under refs/heads), this happens automatically, but for others, we need this option. Currently, git does this by pre-creating the reflog, but alternate ref backends might store reflogs somewhere other than .git/logs. Code that now directly manipulates .git/logs should instead use git plumbing commands. I also added --create-reflog to git tag, just for completeness. In a moment, we will use this argument to make git stash work with alternate ref backends. Signed-off-by: David Turner <> Signed-off-by: Junio C Hamano <>
2015-05-25builtin/show-ref: rewrite to take an object_id argumentMichael Haggerty
Signed-off-by: Michael Haggerty <> Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2015-05-25each_ref_fn: change to take an object_id parameterMichael Haggerty
Change typedef each_ref_fn to take a "const struct object_id *oid" parameter instead of "const unsigned char *sha1". To aid this transition, implement an adapter that can be used to wrap old-style functions matching the old typedef, which is now called "each_ref_sha1_fn"), and make such functions callable via the new interface. This requires the old function and its cb_data to be wrapped in a "struct each_ref_fn_sha1_adapter", and that object to be used as the cb_data for an adapter function, each_ref_fn_adapter(). This is an enormous diff, but most of it consists of simple, mechanical changes to the sites that call any of the "for_each_ref" family of functions. Subsequent to this change, the call sites can be rewritten one by one to use the new interface. Signed-off-by: Michael Haggerty <> Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2015-03-23Merge branch 'jk/tag-h-column-is-a-listing-option'Junio C Hamano
"git tag -h" used to show the "--column" and "--sort" options that are about listing in a wrong section. * jk/tag-h-column-is-a-listing-option: tag: fix some mis-organized options in "-h" listing
2015-03-12tag: fix some mis-organized options in "-h" listingJeff King
Running "git tag -h" currently prints: [...] Tag creation options [...] --column[=<style>] show tag list in columns --sort <type> sort tags Tag listing options --contains <commit> print only tags that contain the commit --points-at <object> print only tags of the object The "--column" and "--sort" options should go under the "Tag listing" group. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-02-17ref_transaction_update(): remove "have_old" parameterMichael Haggerty
Instead, verify the reference's old value if and only if old_sha1 is non-NULL. ref_transaction_delete() will get the same treatment in a moment. Signed-off-by: Michael Haggerty <> Reviewed-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>