summaryrefslogtreecommitdiff
path: root/t/t1512-rev-parse-disambiguation.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-10-12t1512: become resilient to GETTEXT_POISON buildLibravatar Vasco Almeida1-1/+1
The concerned message was marked for translation by 0c99171 ("get_short_sha1: mark ambiguity error for translation", 2016-09-26). Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-27get_short_sha1: make default disambiguation configurableLibravatar Jeff King1-0/+14
When we find ambiguous short sha1s, we may get a disambiguation rule from our caller's context. But if we don't, we fall back to treating all sha1s the same, even though most projects will tend to refer only to commits by their short sha1s. This patch introduces a configuration option that lets the user pick a different fallback (e.g., only commits). It's possible that we may want to make this the default, but it's a good idea to start as a config option for two reasons: 1. It lets people experiment with this and see if it's a good idea (i.e., the "tend to" above is an assumption; we don't really know if this will break some obscure cases). 2. Even if we do flip the default, it gives people an escape hatch if it causes problems (you can sometimes override it by asking for "1234^{tree}", but not all combinations are possible). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26get_short_sha1: list ambiguous objects on errorLibravatar Jeff King1-0/+24
When the user gives us an ambiguous short sha1, we print an error and refuse to resolve it. In some cases, the next step is for them to feed us more characters (e.g., if they were retyping or cut-and-pasting from a full sha1). But in other cases, that might be all they have. For example, an old commit message may have used a 7-character hex that was unique at the time, but is now ambiguous. Git doesn't provide any information about the ambiguous objects it found, so it's hard for the user to find out which one they probably meant. This patch teaches get_short_sha1() to list the sha1s of the objects it found, along with a few bits of information that may help the user decide which one they meant. Here's what it looks like on git.git: $ git rev-parse b2e1 error: short SHA1 b2e1 is ambiguous hint: The candidates are: hint: b2e1196 tag v2.8.0-rc1 hint: b2e11d1 tree hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options' hint: b2e1759 blob hint: b2e18954 blob hint: b2e1895c blob fatal: ambiguous argument 'b2e1': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' We show the tagname for tags, and the date and subject for commits. For trees and blobs, in theory we could dig in the history to find the paths at which they were present. But that's very expensive (on the order of 30s for the kernel), and it's not likely to be all that helpful. Most short references are to commits, so the useful information is typically going to be that the object in question _isn't_ a commit. So it's silly to spend a lot of CPU preemptively digging up the path; the user can do it themselves if they really need to. And of course it's somewhat ironic that we abbreviate the sha1s in the disambiguation hint. But full sha1s would cause annoying line wrapping for the commit lines, and presumably the user is going to just re-issue their command immediately with the corrected sha1. We also restrict the list to those that match any disambiguation hint. E.g.: $ git rev-parse b2e1:foo error: short SHA1 b2e1 is ambiguous hint: The candidates are: hint: b2e1196 tag v2.8.0-rc1 hint: b2e11d1 tree hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options' fatal: Invalid object name 'b2e1'. does not bother reporting the blobs, because they cannot work as a treeish. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26for_each_abbrev: drop duplicate objectsLibravatar Jeff King1-0/+7
If an object appears multiple times in the object database (e.g., in both loose and packed form, or in two separate packs), the disambiguation machinery may see it more than once. The get_short_sha1() function handles this already, but for_each_abbrev() blindly fires the callback for each instance it finds. We can fix this by collecting the output in a sha1 array and de-duplicating it. As a bonus, the sort done for the de-duplication means that our output will be stable, regardless of the order in which the objects are found. Note that the old code normalized the callback's output to 0/1 to store in the 1-bit ds->ambiguous flag (which both halted the iteration and was returned from the for_each_abbrev function). Now that we are using sha1_array, we can return the real value. In practice, it doesn't matter as the sole caller only ever returns 0. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26get_short_sha1: parse tags when looking for treeishLibravatar Jeff King1-0/+7
The treeish disambiguation function tries to peel tags, but it does so by calling: deref_tag(lookup_object(sha1), ...); This will only work if we have previously looked at the tag and created a "struct tag" for it. Since parsing revision arguments typically happens before anything else, this is usually not the case, and we would fail to peel the tag (we are lucky that deref_tag() gracefully handles the NULL and does not segfault). Instead, we can use parse_object(). Note that this is the same fix done by 94d75d1 (get_short_sha1(): correctly disambiguate type-limited abbreviation, 2013-07-01), but that commit fixed only the committish disambiguator, and left the bug in the treeish one. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26get_sha1: propagate flags to child functionsLibravatar Jeff King1-1/+13
The get_sha1() function is actually implementation by many sub-functions, but we do not always pass our flags around to all of those functions. As a result, we may forget that our caller asked us to resolve with GET_SHA1_QUIETLY and output messages. The two triggerable cases are: 1. Resolving treeish:path will resolve the "treeish" portion using GET_SHA1_TREEISH, dropping all other flags. 2. The peel_onion() function did not take flags at all but recurses to get_sha1_1(), which does. The solution for both is to bitwise-OR their new flags with the existing ones (after dropping any mutually exclusive disambiguation flags). This bug can trigger with "git rev-parse --quiet", which asks for quiet resolution. But it can also happen in a more vanilla code path when we do a follow-up ONLY_TO_DIE invocation of get_sha1(), and that's what the tests check. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26get_sha1: avoid repeating ourselves via ONLY_TO_DIELibravatar Jeff King1-0/+6
When the revision code cannot parse an argument like "HEAD:foo", it will call maybe_die_on_misspelt_object_name(), which re-runs get_sha1() with an extra ONLY_TO_DIE flag. We then spend more effort to generate a better error message. Unfortunately, a side effect is that our second call may repeat the same error messages from the original get_sha1() call. You can see this with: $ git show 0017 error: short SHA1 0017 is ambiguous. error: short SHA1 0017 is ambiguous. fatal: ambiguous argument '0017': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' where the second "error:" line comes from the ONLY_TO_DIE call. To fix this, we can make ONLY_TO_DIE imply QUIETLY. This is a little odd, because the whole point of ONLY_TO_DIE is to output error messages. But what we want to do is tell the rest of the get_sha1() code (particularly get_sha1_1()) that the _regular_ messages should be quiet, but the only-to-die ones should not. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-27t/t1512-rev-parse-disambiguation.sh: use the $( ... ) construct for command ↵Libravatar Elia Pinto1-4/+4
substitution The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-11Merge branch 'jc/t1512-fix'Libravatar Junio C Hamano1-10/+22
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-01t1512: correct leftover constants from earlier editionLibravatar Junio C Hamano1-10/+22
The earliest iteration of this test script used a magic string 110282 as the common prefix for ambiguous object names, but the final edition switched the common prefix to 0000000000 (10 "0"s). Unfortunately, instances of the original prefix were left in the comments and a few tests. Replace them with the correct constants. 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-0/+18
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>
2012-07-13t1512: match the "other" object namesLibravatar Junio C Hamano1-3/+3
The test creates 16 objects that share the same prefix, and two other objects that do not. Tweak the test so that the other two share the same prefix that is different from the one that is shared by the 16. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-11t1512: ignore whitespaces in wc -l outputLibravatar Junio C Hamano1-1/+1
Some implementations of sed (e.g. MacOS X) have whitespaces in the output of "wc -l" that reads from the standard input. Ignore these whitespaces by not quoting the command substitution to be compared with the constant "16". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09rev-parse --disambiguate=<prefix>Libravatar Junio C Hamano1-0/+9
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-09rev-parse: A and B in "rev-parse A..B" refer to committishLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09reset: the command takes committishLibravatar Junio C Hamano1-1/+1
This is not strictly correct, in that resetting selected index entries from corresponding paths out of a given tree without moving HEAD is a valid operation, and in such case a tree-ish would suffice. But the existing code already requires a committish in the codepath, so let's be consistent with it for now. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09commit-tree: the command wants a tree and commitsLibravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: --build-fake-ancestor expects blobsLibravatar Junio C Hamano1-1/+1
The "index" line read from the patch to reconstruct a partial preimage tree records the object names of blob objects. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09sha1_name.c: add support for disambiguating other typesLibravatar Junio C Hamano1-1/+1
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-09revision.c: the "log" family, except for "show", takes committishLibravatar Junio C Hamano1-1/+1
Add a field to setup_revision_opt structure and allow these callers to tell the setup_revisions command parsing machinery that short SHA1 it encounters are meant to name committish. This step does not go all the way to connect the setup_revisions() to sha1_name.c yet. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09sha1_name.c: introduce get_sha1_committish()Libravatar Junio C Hamano1-1/+1
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: many short names can only be committishLibravatar Junio C Hamano1-1/+1
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_describe_name() by definition groks only commitsLibravatar Junio C Hamano1-0/+255
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>