summaryrefslogtreecommitdiff
path: root/builtin/name-rev.c
AgeCommit message (Collapse)AuthorFilesLines
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>