summaryrefslogtreecommitdiff
path: root/sha1_name.c
AgeCommit message (Collapse)AuthorFilesLines
2013-10-31sha1-name: trivial style cleanupLibravatar Felipe Contreras1-1/+0
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-20Merge branch 'fc/at-head'Libravatar Junio C Hamano1-4/+34
Instead of typing four capital letters "HEAD", you can say "@" now, e.g. "git log @". * fc/at-head: Add new @ shortcut for HEAD sha1-name: pass len argument to interpret_branch_name()
2013-09-20Merge branch 'rh/peeling-tag-to-tag'Libravatar Junio C Hamano1-3/+5
Make "foo^{tag}" to peel a tag to itself, i.e. no-op., and fail if "foo" is not a tag. "git rev-parse --verify v1.0^{tag}" would be a more convenient way to say "test $(git cat-file -t v1.0) = tag". * rh/peeling-tag-to-tag: peel_onion: do not assume length of x_type globals peel_onion(): add support for <rev>^{tag}
2013-09-12Add new @ shortcut for HEADLibravatar Felipe Contreras1-0/+28
Typing 'HEAD' is tedious, especially when we can use '@' instead. The reason for choosing '@' is that it follows naturally from the ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no operation, and when we don't have those, it makes sens to assume 'HEAD'. So now we can use 'git show @~1', and all that goody goodness. Until now '@' was a valid name, but it conflicts with this idea, so let's make it invalid. Probably very few people, if any, used this name. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-04use 'commit-ish' instead of 'committish'Libravatar Richard Hansen1-3/+3
Replace 'committish' in documentation and comments with 'commit-ish' to match gitglossary(7) and to be consistent with 'tree-ish'. The only remaining instances of 'committish' are: * variable, function, and macro names * "(also committish)" in the definition of commit-ish in gitglossary[7] Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03peel_onion: do not assume length of x_type globalsLibravatar Jeff King1-4/+4
When we are parsing "rev^{foo}", we check "foo" against the various global type strings, like "commit_type", "tree_type", etc. This is nicely abstracted, but then we destroy the abstraction completely by using magic numbers that must match the length of the type strings. We could avoid these magic numbers by using skip_prefix. But taking a step back, we can realize that using the "commit_type" global is not really buying us anything. It is not ever going to change from being "commit" without causing severe breakage to existing uses. And even if it did change for some crazy reason, we would want to evaluate its effects on the "rev^{}" syntax, anyway. Let's just switch these to using a custom string literal, as we do for "rev^{object}". The resulting code is more robust to changes in the type strings, and is more readable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03peel_onion(): add support for <rev>^{tag}Libravatar Richard Hansen1-0/+2
Complete the <rev>^{<type>} family of object descriptors by having <rev>^{tag} dereference <rev> until a tag object is found (or fail if unable). At first glance this may not seem very useful, as commits, trees, and blobs cannot be peeled to a tag, and a tag would just peel to itself. However, this can be used to ensure that <rev> names a tag object: $ git rev-parse --verify v1.8.4^{tag} 04f013dc38d7512eadb915eba22efc414f18b869 $ git rev-parse --verify master^{tag} error: master^{tag}: expected tag type, but the object dereferences to tree type fatal: Needed a single revision Users can already ensure that <rev> is a tag object by checking the output of 'git cat-file -t <rev>', but: * users may expect <rev>^{tag} to exist given that <rev>^{commit}, <rev>^{tree}, and <rev>^{blob} all exist * this syntax is more convenient/natural in some circumstances Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03sha1-name: pass len argument to interpret_branch_name()Libravatar Felipe Contreras1-4/+6
This is useful to make sure we don't step outside the boundaries of what we are interpreting at the moment. For example while interpreting foobar@{u}~1, the job of interpret_branch_name() ends right before ~1, but there's no way to figure that out inside the function, unless the len argument is passed. So let's do that. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-14Revert "Add new @ shortcut for HEAD"Libravatar Junio C Hamano1-17/+0
This reverts commit cdfd94837b27c220f70f032b596ea993d195488f, as it does not just apply to "@" (and forms with modifiers like @{u} applied to it), but also affects e.g. "refs/heads/@/foo", which it shouldn't. The basic idea of giving a short-hand might be good, and the topic can be retried later, but let's revert to avoid affecting existing use cases for now for the upcoming release.
2013-07-31Rename advice.object_name_warning to objectNameWarningLibravatar Thomas Rast1-1/+1
We spell config variables in camelCase instead of with_underscores. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-24Merge branch 'ob/typofixes'Libravatar Junio C Hamano1-1/+1
* ob/typofixes: typofix: in-code comments typofix: documentation typofix: release notes
2013-07-24Merge branch 'jk/cat-file-batch-optim'Libravatar Junio C Hamano1-6/+8
If somebody wants to only know on-disk footprint of an object without having to know its type or payload size, we can bypass a lot of code to cheaply learn it. * jk/cat-file-batch-optim: Fix some sparse warnings sha1_object_info_extended: pass object_info to helpers sha1_object_info_extended: make type calculation optional packed_object_info: make type lookup optional packed_object_info: hoist delta type resolution to helper sha1_loose_object_info: make type lookup optional sha1_object_info_extended: rename "status" to "type" cat-file: disable object/refname ambiguity check for batch mode
2013-07-22typofix: in-code commentsLibravatar Ondřej Bílka1-1/+1
Signed-off-by: Ondřej Bílka <neleai@seznam.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22Merge branch 'nd/const-struct-cache-entry'Libravatar Junio C Hamano1-2/+2
* nd/const-struct-cache-entry: Convert "struct cache_entry *" to "const ..." wherever possible
2013-07-12cat-file: disable object/refname ambiguity check for batch modeLibravatar Jeff King1-6/+8
A common use of "cat-file --batch-check" is to feed a list of objects from "rev-list --objects" or a similar command. In this instance, all of our input objects are 40-byte sha1 ids. However, cat-file has always allowed arbitrary revision specifiers, and feeds the result to get_sha1(). Fortunately, get_sha1() recognizes a 40-byte sha1 before doing any hard work trying to look up refs, meaning this scenario should end up spending very little time converting the input into an object sha1. However, since 798c35f (get_sha1: warn about full or short object names that look like refs, 2013-05-29), when we encounter this case, we spend the extra effort to do a refname lookup anyway, just to print a warning. This is further exacerbated by ca91993 (get_packed_ref_cache: reload packed-refs file when it changes, 2013-06-20), which makes individual ref lookup more expensive by requiring a stat() of the packed-refs file for each missing ref. With no patches, this is the time it takes to run: $ git rev-list --objects --all >objects $ time git cat-file --batch-check='%(objectname)' <objects on the linux.git repository: real 1m13.494s user 0m25.924s sys 0m47.532s If we revert ca91993, the packed-refs up-to-date check, it gets a little better: real 0m54.697s user 0m21.692s sys 0m32.916s but we are still spending quite a bit of time on ref lookup (and we would not want to revert that patch, anyway, which has correctness issues). If we revert 798c35f, disabling the warning entirely, we get a much more reasonable time: real 0m7.452s user 0m6.836s sys 0m0.608s This patch does the moral equivalent of this final case (and gets similar speedups). We introduce a global flag that callers of get_sha1() can use to avoid paying the price for the warning. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-12Merge branch 'nd/warn-ambiguous-object-name' into jk/cat-file-batch-optimLibravatar Junio C Hamano1-2/+23
* nd/warn-ambiguous-object-name: get_sha1: warn about full or short object names that look like refs
2013-07-11Merge branch 'jc/t1512-fix'Libravatar Junio C Hamano1-1/+1
A test that should have failed but didn't revealed a bug that needs to be corrected. * jc/t1512-fix: get_short_sha1(): correctly disambiguate type-limited abbreviation t1512: correct leftover constants from earlier edition
2013-07-09Convert "struct cache_entry *" to "const ..." wherever possibleLibravatar Nguyễn Thái Ngọc Duy1-2/+2
I attempted to make index_state->cache[] a "const struct cache_entry **" to find out how existing entries in index are modified and where. The question I have is what do we do if we really need to keep track of on-disk changes in the index. The result is - diff-lib.c: setting CE_UPTODATE - name-hash.c: setting CE_HASHED - preload-index.c, read-cache.c, unpack-trees.c and builtin/update-index: obvious - entry.c: write_entry() may refresh the checked out entry via fill_stat_cache_info(). This causes "non-const struct cache_entry *" in builtin/apply.c, builtin/checkout-index.c and builtin/checkout.c - builtin/ls-files.c: --with-tree changes stagemask and may set CE_UPDATE Of these, write_entry() and its call sites are probably most interesting because it modifies on-disk info. But this is stat info and can be retrieved via refresh, at least for porcelain commands. Other just uses ce_flags for local purposes. So, keeping track of "dirty" entries is just a matter of setting a flag in index modification functions exposed by read-cache.c. Except unpack-trees, the rest of the code base does not do anything funny behind read-cache's back. The actual patch is less valueable than the summary above. But if anyone wants to re-identify the above sites. Applying this patch, then this: diff --git a/cache.h b/cache.h index 430d021..1692891 100644 --- a/cache.h +++ b/cache.h @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode) #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1) struct index_state { - struct cache_entry **cache; + const struct cache_entry **cache; unsigned int version; unsigned int cache_nr, cache_alloc, cache_changed; struct string_list *resolve_undo; will help quickly identify them without bogus warnings. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-01get_short_sha1(): correctly disambiguate type-limited abbreviationLibravatar Junio C Hamano1-1/+1
One test in t1512 that expects a failure incorrectly passed. The test prepares a commit whose object name begins with ten "0"s, and also prepares a tag that points at the commit. The object name of the tag also begins with ten "0"s. There is no other commit-ish object in the repository whose name begins with such a prefix. Ideally, in such a repository: $ git rev-parse --verify 0000000000^{commit} should yield that commit. If 0000000000 is taken as the commit 0000000000e4f, peeling it to a commmit yields that commit itself, and if 0000000000 is taken as the tag 0000000000f8f, peeling it to a commit also yields the same commit, so in that twisted sense, the extended SHA-1 expression 0000000000^{commit} is unambigous. The test that expects a failure is to check the above command. The reason the test expects a failure is that we did not implement such a "unification" of two candidate objects. What we did (or at least, meant to) implement was to recognise that a commit-ish is required to expand 0000000000, and notice that there are two succh commit-ish, and diagnose the request as ambiguous. However, there was a bug in the logic to check the candidate objects. When the code saw 0000000000f8f (a tag) that shared the shortened prefix (ten "0"s), it tried to make sure that the tag is a commit-ish by looking at the tag object. Because it incorrectly used lookup_object() when the tag has not been parsed, however, we incorrectly declared that the tag is _not_ a commit-ish, leaving the sole commit in the repository, 0000000000e4f, that has the required prefix as "unique match", causing the test to pass when it shouldn't. This fixes the logic to inspect the type of the object a tag refers to, to make the test that is expected to fail correctly fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-11Merge branch 'fc/at-head'Libravatar Junio C Hamano1-37/+66
Instead of typing four capital letters "HEAD", you can say "@" instead. * fc/at-head: sha1_name: compare variable with constant, not constant with variable Add new @ shortcut for HEAD sha1_name: refactor reinterpret() sha1_name: check @{-N} errors sooner sha1_name: reorganize get_sha1_basic() sha1_name: don't waste cycles in the @-parsing loop sha1_name: remove unnecessary braces sha1_name: remove no-op tests: at-combinations: @{N} versus HEAD@{N} tests: at-combinations: increase coverage tests: at-combinations: improve nonsense() tests: at-combinations: check ref names directly tests: at-combinations: simplify setup
2013-06-11Merge branch 'nd/warn-ambiguous-object-name'Libravatar Junio C Hamano1-2/+23
"git cmd <name>", when <name> happens to be a 40-hex string, directly uses the 40-hex string as an object name, even if a ref "refs/<some hierarchy>/<name>" exists. This disambiguation order is unlikely to change, but we should warn about the ambiguity just like we warn when more than one refs/ hierachies share the same name. * nd/warn-ambiguous-object-name: get_sha1: warn about full or short object names that look like refs
2013-06-11Merge branch 'rr/die-on-missing-upstream'Libravatar Junio C Hamano1-7/+17
When a reflog notation is used for implicit "current branch", we did not say which branch and worse said "branch ''". * rr/die-on-missing-upstream: sha1_name: fix error message for @{<N>}, @{<date>} sha1_name: fix error message for @{u}
2013-06-02sha1_name: fix error message for @{<N>}, @{<date>}Libravatar Ramkumar Ramachandra1-1/+10
Currently, when we try to resolve @{<N>} or @{<date>} when the reflog doesn't go back far enough, we get errors like: # on branch master $ git show @{10000} fatal: Log for '' only has 7 entries. $ git show @{10000.days.ago} warning: Log for '' only goes back to Tue, 21 May 2013 14:14:45 +0530. ... # detached HEAD case $ git show @{10000} fatal: Log for '' only has 2005 entries. $ git show master@{10000} fatal: Log for 'master' only has 7 entries. The empty string '' is confusing and does not convey information about whose logs we are inspecting. Change this so that we get: # on branch master $ git show @{10000} fatal: Log for 'master' only has 7 entries. $ git show @{10000.days.ago} warning: Log for 'master' only goes back to Tue, 21 May 2013 14:14:45 +0530. ... # detached HEAD case $ git show @{10000} fatal: Log for 'HEAD' only has 2005 entries. $ git show master@{10000} fatal: Log for 'master' only has 7 entries. Also one of the message strings given to die() now points into real_ref that was not used in that fashion, so stop freeing the underlying storage for it. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Bug-spotted-and-fixed-by: Thomas Rast Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29get_sha1: warn about full or short object names that look like refsLibravatar Nguyễn Thái Ngọc Duy1-2/+23
When we get 40 hex digits, we immediately assume it's an SHA-1. This is the right thing to do because we have no way else to specify an object. If there is a ref with the same object name, it will be ignored. Warn the user about this case because the ref with full object name is likely a mistake, for example git checkout -b $empty_var $(git rev-parse something) advice.object_name_warning is not documented because frankly people should not be aware about it until they encounter this situation. While at there, warn about ambiguation with abbreviated SHA-1 too. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-22sha1_name: fix error message for @{u}Libravatar Ramkumar Ramachandra1-6/+7
Currently, when no (valid) upstream is configured for a branch, you get an error like: $ git show @{u} error: No upstream configured for branch 'upstream-error' error: No upstream configured for branch 'upstream-error' fatal: ambiguous argument '@{u}': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' The "error: " line actually appears twice, and the rest of the error message is useless. In sha1_name.c:interpret_branch_name(), there is really no point in processing further if @{u} couldn't be resolved, and we might as well die() instead of returning an error(). After making this change, you get: $ git show @{u} fatal: No upstream configured for branch 'upstream-error' Also tweak a few tests in t1507 to expect this output. This only turns error() that may be called after we know we are dealing with an @{upstream} marker into die(), without touching silent error returns "return -1" from the function. Any caller that wants to handle an error condition itself will not be hurt by this change, unless they want to see the message from error() and then exit silently without giving its own message, which needs to be fixed anyway. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16strbuf_branchname(): do not double-expand @{-1}~22Libravatar Junio C Hamano1-2/+6
If you were on 'frotz' branch before you checked out your current branch, "git merge @{-1}~22" means the same as "git merge frotz~22". The strbuf_branchname() function, when interpret_branch_name() gives up resolving "@{-1}~22" fully, returns "frotz" and tells the caller that it only resolved "@{-1}" part of the input, mistakes this as a total failure, and appends the whole thing to the result, yielding "frotz@{-1}~22", which does not make any sense. Inspect the return value from interpret_branch_name() a bit more carefully. When it errored out without consuming anything, we will get -1 and we should return the whole thing. Otherwise, we should append the remainder (i.e. "~22" in the earlier example) to the partially resolved name (i.e. "frotz"). The test suite adds enough number of checkout to make @{-12} in the last test in t0100 that tried to check "we haven't flipped branches that many times" error case succeed; raise the number to a hundred. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08sha1_name: compare variable with constant, not constant with variableLibravatar Felipe Contreras1-5/+7
And restructure the if/else to factor out the common "is len positive?" test into a single conditional. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08Add new @ shortcut for HEADLibravatar Felipe Contreras1-0/+17
Typing 'HEAD' is tedious, especially when we can use '@' instead. The reason for choosing '@' is that it follows naturally from the ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no operation, and when we don't have those, it makes sens to assume 'HEAD'. So now we can use 'git show @~1', and all that goody goodness. Until now '@' was a valid name, but it conflicts with this idea, so let's make it invalid. Probably very few people, if any, used this name. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08sha1_name: refactor reinterpret()Libravatar Felipe Contreras1-19/+23
This code essentially replaces part of ref with another ref, for example '@{-1}@{u}' is replaced with 'master@{u}', but this can be reused for other purposes other than nth prior checkouts. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08sha1_name: check @{-N} errors soonerLibravatar Ramkumar Ramachandra1-5/+4
It's trivial to check for them in the @{N} parsing loop. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08sha1_name: reorganize get_sha1_basic()Libravatar Felipe Contreras1-11/+19
Through the years the functionality to handle @{-N} and @{u} has moved around the code, and as a result, code that once made sense, doesn't any more. There is no need to call this function recursively with the branch of @{-N} substituted because dwim_{ref,log} already replaces it. However, there's one corner-case where @{-N} resolves to a detached HEAD, in which case we wouldn't get any ref back. So we parse the nth-prior manually, and deal with it depending on whether it's a SHA-1, or a ref. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08sha1_name: don't waste cycles in the @-parsing loopLibravatar Ramkumar Ramachandra1-1/+1
The @-parsing loop unnecessarily checks for the sequence "@{" from (len - 2) unnecessarily. We can safely check from (len - 4). Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08sha1_name: remove unnecessary bracesLibravatar Felipe Contreras1-3/+2
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08sha1_name: remove no-opLibravatar Felipe Contreras1-1/+1
'at' is always 0, since we can reach this point only if !len && reflog_len, and len=at when reflog is assigned. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03Merge branch 'jc/sha1-name-object-peeler'Libravatar Junio C Hamano1-1/+5
There was no good way to ask "I have a random string that came from outside world. I want to turn it into a 40-hex object name while making sure such an object exists". A new peeling suffix ^{object} can be used for that purpose, together with "rev-parse --verify". * jc/sha1-name-object-peeler: peel_onion(): teach $foo^{object} peeler peel_onion: disambiguate to favor tree-ish when we know we want a tree-ish
2013-03-31peel_onion(): teach $foo^{object} peelerLibravatar Junio C Hamano1-1/+3
A string that names an object can be suffixed with ^{type} peeler to say "I have this object name; peel it until you get this type. If you cannot do so, it is an error". v1.8.2^{commit} asks for a commit that is pointed at an annotated tag v1.8.2; v1.8.2^{tree} unwraps it further to the top-level tree object. A special suffix ^{} (i.e. no type specified) means "I do not care what it unwraps to; just peel annotated tag until you get something that is not a tag". When you have a random user-supplied string, you can turn it to a bare 40-hex object name, and cause it to error out if such an object does not exist, with: git rev-parse --verify "$userstring^{}" for most objects, but this does not yield the tag object name when $userstring refers to an annotated tag. Introduce a new suffix, ^{object}, that only makes sure the given name refers to an existing object. Then git rev-parse --verify "$userstring^{object}" becomes a way to make sure $userstring refers to an existing object. This is necessary because the plumbing "rev-parse --verify" is only about "make sure the argument is something we can feed to get_sha1() and turn it into a raw 20-byte object name SHA-1" and is not about "make sure that 20-byte object name SHA-1 refers to an object that exists in our object store". When the given $userstring is already a 40-hex, by definition "rev-parse --verify $userstring" can turn it into a raw 20-byte object name. With "$userstring^{object}", we can make sure that the 40-hex string names an object that exists in our object store before "--verify" kicks in. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31peel_onion: disambiguate to favor tree-ish when we know we want a tree-ishLibravatar Junio C Hamano1-0/+2
The function already knows when interpreting $foo^{commit} to tell the underlying get_sha1_1() to expect a commit-ish while evaluating $foo. Teach it to do the same when asked for $foo^{tree}; we are expecting a tree-ish and $foo should be disambiguated in favor of a tree-ish, discarding a possible ambiguous match with a blob object. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-26Merge branch 'jc/reflog-reverse-walk'Libravatar Junio C Hamano1-30/+18
An internal function used to implement "git checkout @{-1}" was hard to use correctly. * jc/reflog-reverse-walk: refs.c: fix fread error handling reflog: add for_each_reflog_ent_reverse() API for_each_recent_reflog_ent(): simplify opening of a reflog file for_each_reflog_ent(): extract a helper to process a single entry
2013-03-17sha1_name: pass object name length to diagnose_invalid_sha1_path()Libravatar René Scharfe1-18/+14
The only caller of diagnose_invalid_sha1_path() extracts a substring from an object name by creating a NUL-terminated copy of the interesting part. Add a length parameter to the function and thus avoid the need for an allocation, thereby simplifying the code. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-08reflog: add for_each_reflog_ent_reverse() APILibravatar Junio C Hamano1-30/+18
"git checkout -" is a short-hand for "git checkout @{-1}" and the "@{nth}" notation for a negative number is to find nth previous checkout in the reflog of the HEAD to determine the name of the branch the user was on. We would want to find the nth most recent reflog entry that matches "checkout: moving from X to Y" for this. Unfortunately, reflog is implemented as an append-only file, and the API to iterate over its entries, for_each_reflog_ent(), reads the file in order, giving the entries from the oldest to newer. For the purpose of finding nth most recent one, this API forces us to record the last n entries in a rotating buffer and give the result out only after we read everything. To optimize for a common case of finding the nth most recent one for a small value of n, we also have a side API for_each_recent_reflog_ent() that starts reading near the end of the file, but it still has to read the entries in the "wrong" order. The implementation of understanding @{-1} uses this interface. This all becomes unnecessary if we add an API to let us iterate over reflog entries in the reverse order, from the newest to older. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-22Merge branch 'jc/sha1-name-more'Libravatar Junio C Hamano1-128/+366
Teaches the object name parser things like a "git describe" output is always a commit object, "A" in "git log A" must be a committish, and "A" and "B" in "git log A...B" both must be committish, etc., to prolong the lifetime of abbreviated object names. * jc/sha1-name-more: (27 commits) t1512: match the "other" object names t1512: ignore whitespaces in wc -l output rev-parse --disambiguate=<prefix> rev-parse: A and B in "rev-parse A..B" refer to committish reset: the command takes committish commit-tree: the command wants a tree and commits apply: --build-fake-ancestor expects blobs sha1_name.c: add support for disambiguating other types revision.c: the "log" family, except for "show", takes committish revision.c: allow handle_revision_arg() to take other flags sha1_name.c: introduce get_sha1_committish() sha1_name.c: teach lookup context to get_sha1_with_context() sha1_name.c: many short names can only be committish sha1_name.c: get_sha1_1() takes lookup flags sha1_name.c: get_describe_name() by definition groks only commits sha1_name.c: teach get_short_sha1() a commit-only option sha1_name.c: allow get_short_sha1() to take other flags get_sha1(): fix error status regression sha1_name.c: restructure disambiguation of short names sha1_name.c: correct misnamed "canonical" and "res" ...
2012-07-09rev-parse --disambiguate=<prefix>Libravatar Junio C Hamano1-9/+50
The new option allows you to feed an ambiguous prefix and enumerate all the objects that share it as a prefix of their object names. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09sha1_name.c: add support for disambiguating other typesLibravatar Junio C Hamano1-1/+65
This teaches the revision parser that in "$name:$path" (used for a blob object name), "$name" must be a tree-ish. There are many more places where we know what types of objects are called for. This patch adds support for "commit", "treeish", "tree", and "blob", which could be used in the following contexts: - "git apply --build-fake-ancestor" reads the "index" lines from the patch; they must name blob objects (not even "blob-ish"); - "git commit-tree" reads a tree object name (not "tree-ish"), and zero or more commit object names (not "committish"); - "git reset $rev" wants a committish; "git reset $rev -- $path" wants a treeish. They will come in later patches in the series. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09sha1_name.c: introduce get_sha1_committish()Libravatar Junio C Hamano1-2/+19
Many callers know that the user meant to name a committish by syntactical positions where the object name appears. Calling this function allows the machinery to disambiguate shorter-than-unique abbreviated object names between committish and others. Note that this does NOT error out when the named object is not a committish. It is merely to give a hint to the disambiguation machinery. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09sha1_name.c: teach lookup context to get_sha1_with_context()Libravatar Junio C Hamano1-9/+13
The function takes user input string and returns the object name (binary SHA-1) with mode bits and path when the object was looked up in a tree. Additionally give hints to help disambiguation of abbreviated object names when the caller knows what it is looking for. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09sha1_name.c: many short names can only be committishLibravatar Junio C Hamano1-4/+28
We know that the token "$name" that appear in "$name^{commit}", "$name^4", "$name~4" etc. can only name a committish (either a commit or a tag that peels to a commit). Teach get_short_sha1() to take advantage of that knowledge when disambiguating an abbreviated SHA-1 given as an object name. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09sha1_name.c: get_sha1_1() takes lookup flagsLibravatar Junio C Hamano1-8/+8
This is to pass the disambiguation hints from the caller down the callchain. Nothing is changed in this step, as everybody just passes 0 in the flag. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09sha1_name.c: get_describe_name() by definition groks only commitsLibravatar Junio C Hamano1-1/+2
Teach get_describe_name() to pass the disambiguation hint down the callchain to get_short_sha1(). Also add tests to show various syntactic elements that we could take advantage of the object type information to help disambiguration of abbreviated object names. Many of them are marked as broken, and some of them will be fixed in later patches in this series. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03sha1_name.c: teach get_short_sha1() a commit-only optionLibravatar Junio C Hamano1-0/+9
When the caller knows that the parameter is meant to name a commit, e.g. "56789a" in describe name "v1.2.3-4-g56789a", pass that as a hint so that lower level can use it to disambiguate objects when there is only one commit whose name begins with 56789a even if there are objects of other types whose names share the same prefix. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03sha1_name.c: allow get_short_sha1() to take other flagsLibravatar Junio C Hamano1-3/+4
Instead of a separate "int quietly" argument, make it take "unsigned flags" so that we can pass other options to it. The bit assignment of this flag word is exposed in cache.h because the mechanism will be exposed to callers of the higher layer in later commits in this series. Signed-off-by: Junio C Hamano <gitster@pobox.com>