summaryrefslogtreecommitdiff
path: root/builtin/describe.c
AgeCommit message (Collapse)AuthorFilesLines
2013-05-20describe: Add --first-parent optionLibravatar Mike Crowe1-0/+5
Only consider the first parent commit when walking the commit history. This is useful if you only wish to match tags on your branch after a merge. Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25Merge branch 'jc/describe'Libravatar Junio C Hamano1-21/+20
The "--match=<pattern>" option of "git describe", when used with "--all" to allow refs that are not annotated tags to be used as a base of description, did not restrict the output from the command to those that match the given pattern. We may want to have a looser matching that does not restrict to tags, but that can be done as a follow-up topic; this step is purely a bugfix. * jc/describe: describe: --match=<pattern> must limit the refs even when used with --all
2013-02-28describe: --match=<pattern> must limit the refs even when used with --allLibravatar Junio C Hamano1-21/+20
The logic to limit the refs used for describing with a matching pattern with --match=<pattern> parameter was implemented incorrectly when --all is in effect. It just demoted a ref that did not match the pattern to lower priority---if there aren't other refs with higher priority that describe the given commit, such an unmatching ref was still used. When --match is used, reject refs that do not match the given criteria, so that with or without --all, the output will only use refs that match the pattern. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-24Fix ".git/refs" stragglersLibravatar Greg Price1-2/+2
A couple of references still survive to .git/refs as a tree of all refs. Fix one in docs, one in a -h message, one in a -h message quoted in docs. Signed-off-by: Greg Price <price@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-25Merge branch 'jk/peel-ref'Libravatar Jeff King1-1/+1
Speeds up "git upload-pack" (what is invoked by "git fetch" on the other side of the connection) by reducing the cost to advertise the branches and tags that are available in the repository. * jk/peel-ref: upload-pack: use peel_ref for ref advertisements peel_ref: check object type before loading peel_ref: do not return a null sha1 peel_ref: use faster deref_tag_noverify
2012-10-04peel_ref: do not return a null sha1Libravatar Jeff King1-1/+1
The idea of the peel_ref function is to dereference tag objects recursively until we hit a non-tag, and return the sha1. Conceptually, it should return 0 if it is successful (and fill in the sha1), or -1 if there was nothing to peel. However, the current behavior is much more confusing. For a regular loose ref, the behavior is as described above. But there is an optimization to reuse the peeled-ref value for a ref that came from a packed-refs file. If we have such a ref, we return its peeled value, even if that peeled value is null (indicating that we know the ref definitely does _not_ peel). It might seem like such information is useful to the caller, who would then know not to bother loading and trying to peel the object. Except that they should not bother loading and trying to peel the object _anyway_, because that fallback is already handled by peel_ref. In other words, the whole point of calling this function is that it handles those details internally, and you either get a sha1, or you know that it is not peel-able. This patch catches the null sha1 case internally and converts it into a -1 return value (i.e., there is nothing to peel). This simplifies callers, which do not need to bother checking themselves. Two callers are worth noting: - in pack-objects, a comment indicates that there is a difference between non-peelable tags and unannotated tags. But that is not the case (before or after this patch). Whether you get a null sha1 has to do with internal details of how peel_ref operated. - in show-ref, if peel_ref returns a failure, the caller tries to decide whether to try peeling manually based on whether the REF_ISPACKED flag is set. But this doesn't make any sense. If the flag is set, that does not necessarily mean the ref came from a packed-refs file with the "peeled" extension. But it doesn't matter, because even if it didn't, there's no point in trying to peel it ourselves, as peel_ref would already have done so. In other words, the fallback peeling is guaranteed to fail. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-20i18n: describe: mark parseopt strings for translationLibravatar Nguyễn Thái Ngọc Duy1-14/+14
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11describe: Refresh the index when run with --dirtyLibravatar Allan Caffee1-2/+15
When running git describe --dirty the index should be refreshed. Previously the cached index would cause describe to think that the index was dirty when, in reality, it was just stale. The issue was exposed by python setuptools which hardlinks files into another directory when building a distribution. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01Merge branch 'ab/i18n-st'Libravatar Junio C Hamano1-18/+18
* ab/i18n-st: (69 commits) i18n: git-shortlog basic messages i18n: git-revert split up "could not revert/apply" message i18n: git-revert literal "me" messages i18n: git-revert "Your local changes" message i18n: git-revert basic messages i18n: git-notes GIT_NOTES_REWRITE_MODE error message i18n: git-notes basic commands i18n: git-gc "Auto packing the repository" message i18n: git-gc basic messages i18n: git-describe basic messages i18n: git-clean clean.requireForce messages i18n: git-clean basic messages i18n: git-bundle basic messages i18n: git-archive basic messages i18n: git-status "renamed: " message i18n: git-status "Initial commit" message i18n: git-status "Changes to be committed" message i18n: git-status shortstatus messages i18n: git-status "nothing to commit" messages i18n: git-status basic messages ... Conflicts: builtin/branch.c builtin/checkout.c builtin/clone.c builtin/commit.c builtin/grep.c builtin/merge.c builtin/push.c builtin/revert.c t/t3507-cherry-pick-conflict.sh t/t7607-merge-overwrite.sh
2011-03-23Merge branch 'lt/default-abbrev'Libravatar Junio C Hamano1-1/+5
* lt/default-abbrev: Rename core.abbrevlength back to core.abbrev Make the default abbrev length configurable
2011-03-11Make the default abbrev length configurableLibravatar Linus Torvalds1-1/+5
The default of 7 comes from fairly early in git development, when seven hex digits was a lot (it covers about 250+ million hash values). Back then I thought that 65k revisions was a lot (it was what we were about to hit in BK), and each revision tends to be about 5-10 new objects or so, so a million objects was a big number. These days, the kernel isn't even the largest git project, and even the kernel has about 220k revisions (_much_ bigger than the BK tree ever was) and we are approaching two million objects. At that point, seven hex digits is still unique for a lot of them, but when we're talking about just two orders of magnitude difference between number of objects and the hash size, there _will_ be collisions in truncated hash values. It's no longer even close to unrealistic - it happens all the time. We should both increase the default abbrev that was unrealistically small, _and_ add a way for people to set their own default per-project in the git config file. This is the first step to first make it configurable; the default of 7 is not raised yet. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-describe basic messagesLibravatar Ævar Arnfjörð Bjarmason1-18/+18
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-18for_each_hash: allow passing a 'void *data' pointer to callbackLibravatar Linus Torvalds1-2/+2
For the find_exact_renames() function, this allows us to pass the diff_options structure pointer to the low-level routines. We will use that to distinguish between the "rename" and "copy" cases. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-22Merge branch 'tf/commit-list-prefix'Libravatar Junio C Hamano1-3/+3
* tf/commit-list-prefix: commit: Add commit_list prefix in two function names. Conflicts: sha1_name.c
2010-12-09describe: Delay looking up commits until searching for an inexact matchLibravatar Anders Kaseorg1-15/+22
Now that struct commit.util is not used until after we've checked that the argument doesn't exactly match a tag, we can wait until then to look up the commits for each tag. This avoids a lot of I/O on --exact-match queries in repositories with many tags. For example, 'git describe --exact-match HEAD' becomes about 12 times faster on a cold cache (3.2s instead of 39s) in a linux-2.6 repository with 2000 packed tags. That is a huge win for the interactivity of the __git_ps1 shell prompt helper when on a detached HEAD. Signed-off-by: Anders Kaseorg <andersk@ksplice.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-09describe: Store commit_names in a hash table by commit SHA1Libravatar Anders Kaseorg1-5/+33
describe is currently forced to look up the commit at each tag in order to store the struct commit_name pointers in struct commit.util. For --exact-match queries, those lookups are wasteful. In preparation for removing them, put the commit_names into a hash table, indexed by commit SHA1, that can be used to quickly check for exact matches. Signed-off-by: Anders Kaseorg <andersk@ksplice.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-09describe: Do not use a flex array in struct commit_nameLibravatar Anders Kaseorg1-6/+6
Now add_to_known_names overwrites commit_names in place when multiple tags point to the same commit. This will make it easier to store commit_names in a hash table. Signed-off-by: Anders Kaseorg <andersk@ksplice.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-09describe: Use for_each_rawrefLibravatar Anders Kaseorg1-1/+1
Don't waste time checking for dangling refs; they wouldn't affect the output of 'git describe' anyway. Although this does not gain much performance by itself, it does in conjunction with the next commits. Signed-off-by: Anders Kaseorg <andersk@ksplice.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-29commit: Add commit_list prefix in two function names.Libravatar Thiago Farina1-3/+3
Add commit_list prefix to insert_by_date function and to sort_by_date, so it's clear that these functions refer to commit_list structure. Signed-off-by: Thiago Farina <tfransosi@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-21Merge branch 'sp/maint-describe-tiebreak-with-tagger-date'Libravatar Junio C Hamano1-4/+45
* sp/maint-describe-tiebreak-with-tagger-date: describe: Break annotated tag ties by tagger date tag.c: Parse tagger date (if present) tag.c: Refactor parse_tag_buffer to be saner to program tag.h: Remove unused signature field tag.c: Correct indentation
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+396
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>