summaryrefslogtreecommitdiff
path: root/builtin/name-rev.c
AgeCommit message (Collapse)AuthorFilesLines
2017-07-10Merge branch 'ab/wildmatch'Libravatar Junio C Hamano1-1/+1
Minor code cleanup. * ab/wildmatch: wildmatch: remove unused wildopts parameter
2017-06-24Merge branch 'bw/config-h'Libravatar Junio C Hamano1-0/+1
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-23wildmatch: remove unused wildopts parameterLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Remove the unused wildopts placeholder struct from being passed to all wildmatch() invocations, or rather remove all the boilerplate NULL parameters. This parameter was added back in commit 9b3497cab9 ("wildmatch: rename constants and update prototype", 2013-01-01) as a placeholder for future use. Over 4 years later nothing has made use of it, let's just remove it. It can be added in the future if we find some reason to start using such a parameter. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15config: don't include config.h by defaultLibravatar Brandon Williams1-0/+1
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 <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-30Merge branch 'js/larger-timestamps'Libravatar Junio C Hamano1-1/+1
A follow-up hotfix for a topic already in 'master'. * js/larger-timestamps: name-rev: change a "long" variable to timestamp_t
2017-05-30Merge branch 'jc/name-rev-lw-tag'Libravatar Junio C Hamano1-7/+52
"git describe --contains" penalized light-weight tags so much that they were almost never considered. Instead, give them about the same chance to be considered as an annotated tag that is the same age as the underlying commit would. * jc/name-rev-lw-tag: name-rev: favor describing with tags and use committer date to tiebreak name-rev: refactor logic to see if a new candidate is a better name
2017-05-29Merge branch 'js/plug-leaks'Libravatar Junio C Hamano1-2/+5
Fix memory leaks pointed out by Coverity (and people). * js/plug-leaks: (26 commits) checkout: fix memory leak submodule_uses_worktrees(): plug memory leak show_worktree(): plug memory leak name-rev: avoid leaking memory in the `deref` case remote: plug memory leak in match_explicit() add_reflog_for_walk: avoid memory leak shallow: avoid memory leak line-log: avoid memory leak receive-pack: plug memory leak in update() fast-export: avoid leaking memory in handle_tag() mktree: plug memory leaks reported by Coverity pack-redundant: plug memory leak setup_discovered_git_dir(): plug memory leak setup_bare_git_dir(): help static analysis split_commit_in_progress(): simplify & fix memory leak checkout: fix memory leak cat-file: fix memory leak mailinfo & mailsplit: check for EOF while parsing status: close file descriptor after reading git-rebase-todo difftool: address a couple of resource/memory leaks ...
2017-05-29Merge branch 'bc/object-id'Libravatar Junio C Hamano1-16/+16
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-20name-rev: change a "long" variable to timestamp_tLibravatar Junio C Hamano1-1/+1
Earlier dddbad72 ("timestamp_t: a new data type for timestamps", 2017-04-26) updated all in-core variables, fields and function return values that are used to store "seconds since epoch" to a new type timestamp_t. Unfortunately one variable "cutoff", which is used to keep track of the oldest timestamp of commit we saw on the command line, was "long" and left behind. Update it to timestamp_t as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-08object: convert parse_object* to take struct object_idLibravatar brian m. carlson1-3/+3
Make parse_object, parse_object_or_die, and parse_object_buffer take a pointer to struct object_id. Remove the temporary variables inserted earlier, since they are no longer necessary. Transform all of the callers using the following semantic patch: @@ expression E1; @@ - parse_object(E1.hash) + parse_object(&E1) @@ expression E1; @@ - parse_object(E1->hash) + parse_object(E1) @@ expression E1, E2; @@ - parse_object_or_die(E1.hash, E2) + parse_object_or_die(&E1, E2) @@ expression E1, E2; @@ - parse_object_or_die(E1->hash, E2) + parse_object_or_die(E1, E2) @@ expression E1, E2, E3, E4, E5; @@ - parse_object_buffer(E1.hash, E2, E3, E4, E5) + parse_object_buffer(&E1, E2, E3, E4, E5) @@ expression E1, E2, E3, E4, E5; @@ - parse_object_buffer(E1->hash, E2, E3, E4, E5) + parse_object_buffer(E1, E2, E3, E4, E5) Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-08name-rev: avoid leaking memory in the `deref` caseLibravatar Johannes Schindelin1-2/+5
When the `name_rev()` function is asked to dereference the tip name, it allocates memory. But when it turns out that another tip already described the commit better than the current one, we forgot to release the memory. Pointed out by Coverity. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-02builtin/name-rev: convert to struct object_idLibravatar brian m. carlson1-14/+14
Convert all the uses of unsigned char [20] to struct object_id. Also, convert some hard-coded integers into constants. name_rev_line accepts a wide variety of free-form input and only interprets 40-character hex values, passing through everything else. Consequently, it is not a good candidate for parse_oid_hex, which is much stricter. This change is a prerequisite for converting parse_object. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-27timestamp_t: a new data type for timestampsLibravatar Johannes Schindelin1-3/+3
Git's source code assumes that unsigned long is at least as precise as time_t. Which is incorrect, and causes a lot of problems, in particular where unsigned long is only 32-bit (notably on Windows, even in 64-bit versions). So let's just use a more appropriate data type instead. In preparation for this, we introduce the new `timestamp_t` data type. By necessity, this is a very, very large patch, as it has to replace all timestamps' data type in one go. As we will use a data type that is not necessarily identical to `time_t`, we need to be very careful to use `time_t` whenever we interact with the system functions, and `timestamp_t` everywhere else. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-30name-rev: replace static buffer with strbufLibravatar Jeff King1-9/+12
When name-rev needs to format an actual name, we do so into a fixed-size buffer. That includes the actual ref tip, as well as any traversal information. Since refs can exceed 1024 bytes, this means you can get a bogus result. E.g., doing: git tag $(perl -e 'print join("/", 1..1024)') git describe --contains HEAD^ results in ".../282/283", when it should be ".../1023/1024~1". We can solve this by using a heap buffer. We'll use a strbuf, which lets us write into the same buffer from our loop without having to reallocate. Signed-off-by: Jeff King <peff@peff.net>
2017-03-29name-rev: favor describing with tags and use committer date to tiebreakLibravatar Junio C Hamano1-9/+44
"git name-rev" assigned a phony "far in the future" date to tips of refs that are not pointing at tag objects, and favored names based on a ref with the oldest date. This made it almost impossible for an unannotated tags and branches to be counted as a viable base, which was especially problematic when the command is run with the "--tags" option. If an unannotated tag that points at an ancient commit and an annotated tag that points at a much newer commit reaches the commit that is being named, the old unannotated tag was ignored. Update the "taggerdate" field of the rev-name structure, which is initialized from the tip of ref, to have the committer date if the object at the tip of ref is a commit, not a tag, so that we can optionally take it into account when doing "is this name better?" comparison logic. When "name-rev" is run without the "--tags" option, the general expectation is still to name the commit based on a tag if possible, but use non-tag refs as fallback, and tiebreak among these non-tag refs by favoring names with shorter hops from the tip. The use of a phony "far in the future" date in the original code was an effective way to ensure this expectation is held: a non-tag tip gets the same "far in the future" timestamp, giving precedence to tags, and among non-tag tips, names with shorter hops are preferred over longer hops, without taking the "taggerdate" into account. As we are taking over the "taggerdate" field to store the committer date for tips with commits: (1) keep the original logic when comparing names based on two refs both of which are from refs/tags/; (2) favoring a name based on a ref in refs/tags/ hierarchy over a ref outside the hierarchy; (3) between two names based on a ref both outside refs/tags/, give precedence to a name with shorter hops and use "taggerdate" only to tie-break. A change to t4202 is a natural consequence. The test creates a commit on a branch "side" and points at it with an unannotated tag "refs/tags/side-2". The original code couldn't decide which one to favor at all, and gave a name based on a branch (simply because refs/heads/side sorts earlier than refs/tags/side-2). Because the updated logic is taught to favor refs in refs/tags/ hierarchy, the the test is updated to expect to see tags/side-2 instead. [mjg: open-coded the comparisons in is_better_name(), dropping a helper macro used in the original] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-29name-rev: refactor logic to see if a new candidate is a better nameLibravatar Junio C Hamano1-3/+13
When we encounter a new ref that could describe the commit we are looking at, we compare the name that is formed using that ref and the name we found so far and pick a better one. Factor the comparison logic out to a separate helper function, while keeping the current logic the same (i.e. a name that is based on an older tag is better, and if two tags of the same age can reach the commit, the one with fewer number of hops to reach the commit is better). Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23name-rev: add support to exclude refs by pattern matchLibravatar Jacob Keller1-1/+13
Extend git-name-rev to support excluding refs which match shell patterns using --exclude. These patterns can be used to limit the scope of refs by excluding any ref that matches one of the --exclude patterns. A ref will only be used for naming when it matches at least one --refs pattern but does not match any of the --exclude patterns. Thus, --exclude patterns are given precedence over --refs patterns. For example, suppose you wish to name a series of commits based on an official release tag of the form "v*" but excluding any pre-release tags which match "*rc*". You can use the following to do so: git name-rev --refs="v*" --exclude="*rc*" --all Add tests and update Documentation for this change. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23name-rev: extend --refs to accept multiple patternsLibravatar Jacob Keller1-12/+34
Teach git name-rev to take multiple --refs stored as a string list of patterns. The list of patterns will be matched inclusively, and each ref only needs to match one pattern to be included. A ref will only be excluded if it does not match any of the given patterns. Additionally, if any of the patterns would allow abbreviation, then we will abbreviate the ref, even if another pattern is more strict and would not have allowed abbreviation on its own. Add tests and documentation for this change. The tests expected output is dynamically generated. This is in order to avoid hard-coding a commit object name in the test results (as the expected output is to simply leave the commit object unnamed). Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-29use QSORTLibravatar René Scharfe1-2/+1
Apply the semantic patch contrib/coccinelle/qsort.cocci to the code base, replacing calls of qsort(3) with QSORT. The resulting code is shorter and supports empty arrays with NULL pointers. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-03Merge branch 'js/name-rev-use-oldest-ref'Libravatar Junio C Hamano1-6/+13
"git describe --contains" often made a hard-to-justify choice of tag to give name to a given commit, because it tried to come up with a name with smallest number of hops from a tag, causing an old commit whose close descendant that is recently tagged were not described with respect to an old tag but with a newer tag. It did not help that its computation of "hop" count was further tweaked to penalize being on a side branch of a merge. The logic has been updated to favor using the tag with the oldest tagger date, which is a lot easier to explain to the end users: "We describe a commit in terms of the (chronologically) oldest tag that contains the commit." * js/name-rev-use-oldest-ref: name-rev: include taggerdate in considering the best name
2016-04-22name-rev: include taggerdate in considering the best nameLibravatar Johannes Schindelin1-6/+13
We most likely want the oldest tag that contained the commit to be reported. So let's remember the taggerdate, and make it more important than anything else when choosing the best name for a given commit. Suggested by Linus Torvalds. Note that we need to update t9903 because it tested for the old behavior (which preferred the description "b1~1" over "tags/t2~1"). We might want to introduce a --heed-taggerdate option, and make the new behavior dependent on that, if it turns out that some scripts rely on the old name-rev method. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-20Remove get_object_hash.Libravatar brian m. carlson1-2/+2
Convert all instances of get_object_hash to use an appropriate reference to the hash member of the oid member of struct object. This provides no functional change, as it is essentially a macro substitution. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20Convert struct object to object_idLibravatar brian m. carlson1-4/+4
struct object is one of the major data structures dealing with object IDs. Convert it to use struct object_id instead of an unsigned char array. Convert get_object_hash to refer to the new member as well. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20Add several uses of get_object_hash.Libravatar brian m. carlson1-3/+3
Convert most instances where the sha1 member of struct object is dereferenced to use get_object_hash. Most instances that are passed to functions that have versions taking struct object_id, such as get_sha1_hex/get_oid_hex, or instances that can be trivially converted to use struct object_id instead, are not converted. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-10-05name-rev: use strip_suffix to avoid magic numbersLibravatar Jeff King1-5/+4
The manual size computations here are correct, but using strip_suffix makes that obvious, and hopefully communicates the intent of the code more clearly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25replace trivial malloc + sprintf / strcpy calls with xstrfmtLibravatar Jeff King1-8/+5
It's a common pattern to do: foo = xmalloc(strlen(one) + strlen(two) + 1 + 1); sprintf(foo, "%s %s", one, two); (or possibly some variant with strcpy()s or a more complicated length computation). We can switch these to use xstrfmt, which is shorter, involves less error-prone manual computation, and removes many sprintf and strcpy calls which make it harder to audit the code for real buffer overflows. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-25name_ref(): rewrite to take an object_id argumentLibravatar Michael Haggerty1-6/+4
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-25each_ref_fn: change to take an object_id parameterLibravatar Michael Haggerty1-1/+3
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 <mhagger@alum.mit.edu> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-14standardize usage info string formatLibravatar Alex Henrie1-3/+3
This patch puts the usage info strings that were not already in docopt- like format into docopt-like format, which will be a litle easier for end users and a lot easier for translators. Changes include: - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing <foobar>* with [<foobar>...] Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-19use xstrfmt to replace xmalloc + strcpy/strcatLibravatar Jeff King1-4/+1
It's easy to get manual allocation calculations wrong, and the use of strcpy/strcat raise red flags for people looking for buffer overflows (though in this case each site was fine). It's also shorter to use xstrfmt, and the printf-format tends to be easier for a reader to see what the final string will look like. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-20use wildmatch() directly without fnmatch() wrapperLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Make it clear that we don't use fnmatch() anymore. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-17Merge branch 'cc/starts-n-ends-with'Libravatar Junio C Hamano1-3/+3
Remove a few duplicate implementations of prefix/suffix comparison functions, and rename them to starts_with and ends_with. * cc/starts-n-ends-with: replace {pre,suf}fixcmp() with {starts,ends}_with() strbuf: introduce starts_with() and ends_with() builtin/remote: remove postfixcmp() and use suffixcmp() instead environment: normalize use of prefixcmp() by removing " != 0"
2013-12-05replace {pre,suf}fixcmp() with {starts,ends}_with()Libravatar Christian Couder1-3/+3
Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05Merge branch 'jk/robustify-parse-commit'Libravatar Junio C Hamano1-2/+1
* jk/robustify-parse-commit: checkout: do not die when leaving broken detached HEAD use parse_commit_or_die instead of custom message use parse_commit_or_die instead of segfaulting assume parse_commit checks for NULL commit assume parse_commit checks commit->object.parsed log_tree_diff: die when we fail to parse a commit
2013-10-24assume parse_commit checks commit->object.parsedLibravatar Jeff King1-2/+1
The parse_commit function will check the "parsed" flag of the object and do nothing if it is set. There is no need for callers to check the flag themselves, and doing so only clutters the code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-07branch, commit, name-rev: ease up boolean conditionsLibravatar Stefan Beller1-1/+1
Now that the variables are set by OPT_BOOL, which makes sure to have the values being 0 or 1 after parsing, we do not need the double negation to map any other value to 1 for integer variables. Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05Replace deprecated OPT_BOOLEAN by OPT_BOOLLibravatar Stefan Beller1-6/+6
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27). All occurrences of the respective variables have been reviewed and none of them relied on the counting up mechanism, but all of them were using the variable as a true boolean. This patch does not change semantics of any command intentionally. Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18describe: fix --contains when a tag is given as inputLibravatar Junio C Hamano1-1/+16
"git describe" takes a commit and gives it a name based on tags in its neighbourhood. The command does take a commit-ish but when given a tag that points at a commit, it should dereference the tag before computing the name for the commit. As the whole processing is internally delegated to name-rev, if we unwrap tags down to the underlying commit when invoking name-rev, it will make the name-rev issue an error message based on the unwrapped object name (i.e. either 40-hex object name, or "$tag^0") that is different from what the end-user gave to the command when the commit cannot be described. Introduce an internal option --peel-tag to the name-rev to tell it to unwrap a tag in its input from the command line. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18name-rev: differentiate between tags and commits they point atLibravatar Junio C Hamano1-8/+16
"git name-rev --stdin" has been fixed to convert an object name that points at a tag to a refname of the tag. The codepath to handle its command line arguments, however, fed the commit that the tag points at to the underlying naming machinery. With this fix, you will get this: $ git name-rev --refs=tags/\* --name-only $(git rev-parse v1.8.3 v1.8.3^0) v1.8.3 v1.8.3^0 which is the same as what you would get from the fixed "--stdin" variant: $ git rev-parse v1.8.3 v1.8.3^0 | git name-rev --refs=tags/\* --name-only v1.8.3 v1.8.3^0 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09name-rev: allow converting the exact object name at the tip of a refLibravatar Junio C Hamano1-1/+58
"git name-rev" is supposed to convert given object names into strings that name the same objects based on refs, that can be fed to "git rev-parse" to get the same object names back, so the output for the commit object v1.8.3^0 (i.e. the commit tagged as v1.8.3) $ git rev-parse v1.8.3 v1.8.3^0 | git name-rev --stdin 8af06057d0c31a24e8737ae846ac2e116e8bafb9 edca4152560522a431a51fc0a06147fc680b5b18 (tags/v1.8.3^0) has to have "^0" at the end, as "edca41" is a commit, not the tag that references it. But we do not get anything for the tag object (8af0605) itself. This is because the command however did not bother to see if the object is at the tip of some ref, and failed to convert a tag object. Teach it to show this instead: $ git rev-parse v1.8.3 v1.8.3^0 | git name-rev --stdin 8af06057d0c31a24e8737ae846ac2e116e8bafb9 (tags/v1.8.3) edca4152560522a431a51fc0a06147fc680b5b18 (tags/v1.8.3^0) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-07name-ref: factor out name shortening logic from name_ref()Libravatar Junio C Hamano1-7/+12
The logic will be used in a new codepath for showing exact matches. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-18name-rev: allow to specify a subpath for --refs optionLibravatar Namhyung Kim1-7/+29
When an user wants to filter specific ref using the --refs option, the pattern needs to match the full ref, e.g. --refs=refs/tags/v1.*. It'd be convenient to specify a subpath of ref pattern. For example, --refs=origin/* can find refs/remotes/origin/master by searching the pattern against its substrings in turn: refs/remotes/origin/master remotes/origin/master origin/master If it finds a match in a subpath, unambigous part of the ref path will be removed in the output. Signed-off-by: Namhyung Kim <namhyung.kim@lge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-20i18n: name-rev: mark parseopt strings for translationLibravatar Nguyễn Thái Ngọc Duy1-11/+11
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-18Sync with 1.7.7.4Libravatar Junio C Hamano1-1/+1
2011-11-18Merge branch 'jc/maint-name-rev-all' into maintLibravatar Junio C Hamano1-1/+1
* jc/maint-name-rev-all: name-rev --all: do not even attempt to describe non-commit object
2011-10-03name-rev: split usage stringLibravatar René Scharfe1-1/+3
Give each mode of operation (all, from stdin, given commits) its own usage line to make it easier to see that they are mutually exclusive. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-29object.h: Add OBJECT_ARRAY_INIT macro and make use of it.Libravatar Thiago Farina1-1/+1
Signed-off-by: Thiago Farina <tfransosi@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+305
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>