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