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