summaryrefslogtreecommitdiff
path: root/sha1_name.c
AgeCommit message (Collapse)AuthorFilesLines
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>
2012-07-03get_sha1(): fix error status regressionLibravatar Junio C Hamano1-1/+1
In finish_object_disambiguation(), if the candidate hasn't been checked, there are two cases: - It is the first and only object that match the prefix; or - It replaced another object that matched the prefix but that object did not satisfy ds->fn() callback. And the former case we set ds->candidate_ok to true without doing anything else, while for the latter we check the candidate, which may set ds->candidate_ok to false. At this point in the code, ds->candidate_ok can be false only if this last-round check found that the candidate does not pass the check, because the state after update_candidates() returns cannot satisfy !ds->ambiguous && ds->candidate_exists && ds->candidate_checked and !ds->canidate_ok at the same time. Hence, when we execute this "return", we know we have seen more than one object that match the prefix (and none of them satisfied ds->fn), meaning that we should say "the short name is ambiguous", not "there is no object that matches the prefix". Noticed by Jeff King. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03sha1_name.c: restructure disambiguation of short namesLibravatar Junio C Hamano1-60/+112
We try to find zero, one or more matches from loose objects and packed objects independently and then decide if the given short object name is unique across them. Instead, introduce a "struct disambiguate_state" that keeps track of what we have found so far, that can be one of: - We have seen one object that _could_ be what we are looking for; - We have also checked that object for additional constraints (if any), and found that the object satisfies it; - We have also checked that object for additional constraints (if any), and found that the object does not satisfy it; or - We have seen more than one objects that satisfy the constraints. and pass it to the enumeration functions for loose and packed objects. The disambiguation state can optionally take a callback function that takes a candidate object name and reports if the object satisifies additional criteria (e.g. when the caller knows that the short name must refer to a commit, this mechanism can be used to check the type of the given object). Compared to the earlier attempt, this round avoids the optional check if there is only one candidate that matches the short name in the first place. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03sha1_name.c: correct misnamed "canonical" and "res"Libravatar Junio C Hamano1-22/+22
These are hexadecimal and binary representation of the short object name given to the callchain as its input. Rename them with _pfx suffix to make it clear they are prefixes, and call them hex and bin respectively. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03sha1_name.c: refactor find_short_packed_object()Libravatar Junio C Hamano1-47/+56
Extract the logic to find object(s) that match a given prefix inside a single pack into a separate helper function, and give it a bit more comment. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03sha1_name.c: rename "now" to "current"Libravatar Junio C Hamano1-8/+8
This variable points at the element we are currently looking at, and does not have anything to do with the current time which the name "now" implies. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03sha1_name.c: clarify what "fake" is for in find_short_object_filename()Libravatar Junio C Hamano1-0/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03sha1_name.c: get rid of get_sha1_with_mode()Libravatar Junio C Hamano1-8/+0
There are only two callers, and they will benefit from being able to pass disambiguation hints to underlying get_sha1_with_context() API once it happens. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03sha1_name.c: get rid of get_sha1_with_mode_1()Libravatar Junio C Hamano1-4/+16
The only external caller is setup.c that tries to give a nicer error message when an object name is misspelt (e.g. "HEAD:cashe.h"). Retire it and give the caller a dedicated and more intuitive API function maybe_die_on_misspelt_object_name(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-02sha1_name.c: hide get_sha1_with_context_1() uglinessLibravatar Junio C Hamano1-13/+18
There is no outside caller that cares about the "only-to-die" ugliness. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-28Merge branch 'mm/verify-filename-fix'Libravatar Junio C Hamano1-1/+1
"git diff COPYING HEAD:COPYING" gave a nonsense error message that claimed that the treeish HEAD did not have COPYING in it.
2012-06-18sha1_name: do not trigger detailed diagnosis for file argumentsLibravatar Matthieu Moy1-1/+1
diagnose_invalid_sha1_path() is meant to be called to diagnose a misspelt <treeish>:<pathname> when <pathname> does not exist in <treeish>. However, the code may call it if <treeish>:<pathname> is invalid (which triggers another call with only_to_die == 1), but for another reason. This happens when calling e.g. git log existing-file HEAD:existing-file because existing-file is a path and not a revision, the code verifies that the arguments that follow to be paths. This leads to an incorrect message like "existing-file does not exist in HEAD", even though the path exists in HEAD. Check that the search for <pathname> in <treeish> fails before triggering the diagnosis. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-18sha1_name.c: indentation fixLibravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15i18n: mark @{upstream} error messages for translationLibravatar Zbigniew Jędrzejewski-Szmek1-4/+4
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15Be more specific if upstream branch is not trackedLibravatar Zbigniew Jędrzejewski-Szmek1-1/+6
If the branch configured as upstream didn't have a local tracking branch, git said "Upstream branch not found". We can be more helpful, and separate the cases when upstream is not configured, and when it is configured, but the upstream branch is not tracked in a local branch. The following configuration leads to the second scenario: [remote "origin"] url = ... fetch = refs/heads/master [branch "master"] remote = origin merge = refs/heads/master 'git pull' will work on master, but master@{upstream} is not defined. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15Provide better message for barnhc_wiht_tpyo@{u}Libravatar Zbigniew Jędrzejewski-Szmek1-1/+4
Instead of just saying that no upstream exists for such branch, which is true but not very helpful, check that there's no refs/heads/barnhc_wiht_tpyo and tell it to the user. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15Provide branch name in error message when using @{u}Libravatar Zbigniew Jędrzejewski-Szmek1-4/+8
When using @{u} or @{upstream} it is common to omit the branch name, implying current branch. If the upstream is not configured, the error message was "No upstream branch found for ''". When resolving '@{u}', branch_get() is called, which almost always returns a description of a branch. This allows us to use a branch name in the error message, even if the user said something like '@{u}'. The only case when branch_get() returns NULL is when HEAD points to so something which is not a branch. Of course this also means that no upstream is configured, but it is better to directly say that HEAD does not point to a branch. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21Merge branch 'jc/broken-ref-dwim-fix'Libravatar Junio C Hamano1-85/+0
* jc/broken-ref-dwim-fix: resolve_ref(): report breakage to the caller without warning resolve_ref(): expose REF_ISBROKEN flag refs.c: move dwim_ref()/dwim_log() from sha1_name.c
2011-10-12refs.c: move dwim_ref()/dwim_log() from sha1_name.cLibravatar Junio C Hamano1-85/+0
Both dwim_ref()/dwim_log() functions are intimately related to the ref parsing rules defined in refs.c and better fits there. Move them together with substitute_branch_name(), a file scope static helper function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-10Merge branch 'mh/check-ref-format-3'Libravatar Junio C Hamano1-2/+2
* mh/check-ref-format-3: (23 commits) add_ref(): verify that the refname is formatted correctly resolve_ref(): expand documentation resolve_ref(): also treat a too-long SHA1 as invalid resolve_ref(): emit warnings for improperly-formatted references resolve_ref(): verify that the input refname has the right format remote: avoid passing NULL to read_ref() remote: use xstrdup() instead of strdup() resolve_ref(): do not follow incorrectly-formatted symbolic refs resolve_ref(): extract a function get_packed_ref() resolve_ref(): turn buffer into a proper string as soon as possible resolve_ref(): only follow a symlink that contains a valid, normalized refname resolve_ref(): use prefixcmp() resolve_ref(): explicitly fail if a symlink is not readable Change check_refname_format() to reject unnormalized refnames Inline function refname_format_print() Make collapse_slashes() allocate memory for its result Do not allow ".lock" at the end of any refname component Refactor check_refname_format() Change check_ref_format() to take a flags argument Change bad_ref_char() to return a boolean value ...
2011-10-05Change check_ref_format() to take a flags argumentLibravatar Michael Haggerty1-2/+2
Change check_ref_format() to take a flags argument that indicates what is acceptable in the reference name (analogous to "git check-ref-format"'s "--allow-onelevel" and "--refspec-pattern"). This is more convenient for callers and also fixes a failure in the test suite (and likely elsewhere in the code) by enabling "onelevel" and "refspec-pattern" to be allowed independently of each other. Also rename check_ref_format() to check_refname_format() to make it obvious that it deals with refnames rather than references themselves. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-15Allow git merge ":/<pattern>"Libravatar Junio C Hamano1-6/+0
It probably is not such a good idea to use ":/<pattern>" to specify which commit to merge, as ":/<pattern>" can often hit unexpected commits, but somebody tried it and got a nonsense error message: fatal: ':/Foo bar' does not point to a commit So here is a for-the-sake-of-consistency update that is fairly useless that allows users to carefully try not shooting in the foot. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-23Merge branch 'jc/magic-pathspec'Libravatar Junio C Hamano1-8/+9
* jc/magic-pathspec: setup.c: Fix some "symbol not declared" sparse warnings t3703: Skip tests using directory name ":" on Windows revision.c: leave a note for "a lone :" enhancement t3703, t4208: add test cases for magic pathspec rev/path disambiguation: further restrict "misspelled index entry" diag fix overslow :/no-such-string-ever-existed diagnostics fix overstrict :<path> diagnosis grep: use get_pathspec() correctly pathspec: drop "lone : means no pathspec" from get_pathspec() Revert "magic pathspec: add ":(icase)path" to match case insensitively" magic pathspec: add ":(icase)path" to match case insensitively magic pathspec: futureproof shorthand form magic pathspec: add tentative ":/path/from/top/level" pathspec support
2011-05-10fix overslow :/no-such-string-ever-existed diagnosticsLibravatar Junio C Hamano1-8/+9
"git cmd :/no-such-string-ever-existed" runs an extra round of get_sha1() since 009fee4 (Detailed diagnosis when parsing an object name fails., 2009-12-07). Once without error diagnosis to see there is no commit with such a string in the log message (hence "it cannot be a ref"), and after seeing that :/no-such-string-ever-existed is not a filename (hence "it cannot be a path, either"), another time to give "better diagnosis". The thing is, the second time it runs, we already know that traversing the history all the way down to the root will _not_ find any matching commit. Rename misguided "gently" parameter, which is turned off _only_ when the "detailed diagnosis" codepath knows that it cannot be a ref and making the call only for the caller to die with a message. Flip its meaning (and adjust the callers) and call it "only_to_die", which is not a great name, but it describes far more clearly what the codepaths that switches their behaviour based on this variable do. On my box, the command spends ~1.8 seconds without the patch to make the report; with the patch it spends ~1.12 seconds. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-10fix overstrict :<path> diagnosisLibravatar Junio C Hamano1-1/+1
Given "git log :", we get a disambiguation message that tries to be helpful and yet totally misses the point, i.e. $ git log : fatal: Path '' does not exist (neither on disk nor in the index). $ git log :/ fatal: Path '/' exists on disk, but not in the index. An empty path nor anything that begins with '/' cannot possibly in the index, and it is wrong to guess that the user might have meant to access such an index entry. It should yield the same error message as "git log '*.c'", i.e. $ git log '*.c' fatal: ambiguous argument '*.c': unknown revision or path not in the working tree. Use '--' to separate paths from revisions Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-03sha1_name: Suggest commit:./file for path in subdirLibravatar Michael J Gruber1-4/+7
Currently, the "Did you mean..." message suggests "commit:fullpath" only. Extend this to show the more convenient "commit:./file" form also. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10Revert "core.abbrevguard: Ensure short object names stay unique a bit longer"Libravatar Junio C Hamano1-3/+1
This reverts commit 72a5b561fc1c4286bc7c5b0693afc076af261e1f, as adding fixed number of hexdigits more than necessary to make one object name locally unique does not help in futureproofing the uniqueness of names we generate today. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-22Merge branch 'tf/commit-list-prefix'Libravatar Junio C Hamano1-1/+1
* tf/commit-list-prefix: commit: Add commit_list prefix in two function names. Conflicts: sha1_name.c
2010-12-21Merge branch 'nd/oneline-sha1-name-from-specific-ref'Libravatar Junio C Hamano1-28/+55
* nd/oneline-sha1-name-from-specific-ref: get_sha1: handle special case $commit^{/} get_sha1: support $commit^{/regex} syntax get_sha1_oneline: make callers prepare the commit list to traverse get_sha1_oneline: fix lifespan rule of temp_commit_buffer variable
2010-12-16get_sha1: handle special case $commit^{/}Libravatar Nguyễn Thái Ngọc Duy1-0/+7
Empty regex pattern should always match. But the exact behavior of regexec() may vary. Because it always matches anyway, we can just return 'matched' without calling regex machinery. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-16Merge branch 'nd/extended-sha1-relpath'Libravatar Junio C Hamano1-2/+35
* nd/extended-sha1-relpath: get_sha1: teach ":$n:<path>" the same relative path logic get_sha1: support relative path ":path" syntax Make prefix_path() return char* without const Conflicts: sha1_name.c
2010-12-14get_sha1: support $commit^{/regex} syntaxLibravatar Nguyễn Thái Ngọc Duy1-11/+26
This works like ":/regex" syntax that finds a recently created commit starting from all refs, but limits the discovery to those reachable from the named commit. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-12get_sha1_oneline: make callers prepare the commit list to traverseLibravatar Nguyễn Thái Ngọc Duy1-8/+11
This gives callers more control, i.e. which ref will be searched from. They must prepare the list ordered by committer date. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-12get_sha1_oneline: fix lifespan rule of temp_commit_buffer variableLibravatar Junio C Hamano1-11/+13
This is trying to free only what we ourselves read (as opposed to what we borrowed from commit->buffer) but do so lazily only to work around the fact that the code has many irregular exit points, and doing it right makes it necessary to call free() from many different places in the loop. Rewrite the structure of the code inside the loop so that the variable has to live within a single iteration, ever. This should make the logic easier to follow as well. Also we didn't free a temporary commit list we kept to hold the original set of commits. Free it. Noticed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-09get_sha1: teach ":$n:<path>" the same relative path logicLibravatar Junio C Hamano1-6/+8
We taught the object name parser to take ":./<path>", ":../<path>", etc. and understand them to be relative to the current working directory. Given that ":<path>" is just a short-hand for ":0:<path>" (i.e. "take stage #0 of that path"), we should allow ":$n:<path>" to interpret them the same way. Signed-off-by: Junio C Hamano <gitster@pobox.com>