summaryrefslogtreecommitdiff
path: root/sha1_name.c
AgeCommit message (Collapse)AuthorFilesLines
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>
2010-12-07get_sha1: support relative path ":path" syntaxLibravatar Nguyễn Thái Ngọc Duy1-3/+34
Currently :path and ref:path can be used to refer to a specific object in index or ref respectively. "path" component is absolute path. This patch allows "path" to be written as "./path" or "../path", which is relative to user's original cwd. This does not work in commands for which startup_info is NULL (i.e. non-builtin ones, it seems none of them needs this anyway). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-03Merge branch 'jn/thinner-wrapper'Libravatar Junio C Hamano1-0/+18
* jn/thinner-wrapper: Remove pack file handling dependency from wrapper.o pack-objects: mark file-local variable static wrapper: give zlib wrappers their own translation unit strbuf: move strbuf_branchname to sha1_name.c path helpers: move git_mkstemp* to wrapper.c wrapper: move odb_* to environment.c wrapper: move xmmap() to sha1_file.c
2010-12-03Merge branch 'jc/abbrev-guard'Libravatar Junio C Hamano1-1/+3
* jc/abbrev-guard: core.abbrevguard: Ensure short object names stay unique a bit longer
2010-11-29commit: Add commit_list prefix in two function names.Libravatar Thiago Farina1-1/+1
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-11-17Merge branch 'ks/no-textconv-symlink'Libravatar Junio C Hamano1-0/+2
* ks/no-textconv-symlink: blame,cat-file --textconv: Don't assume mode is ``S_IFREF | 0664'' blame,cat-file: Demonstrate --textconv is wrongly running converter on symlinks blame,cat-file: Prepare --textconv tests for correctly-failing conversion program
2010-11-10strbuf: move strbuf_branchname to sha1_name.cLibravatar Jonathan Nieder1-0/+18
strbuf_branchname is a thin wrapper around interpret_branch_name from sha1_name.o. Most strbuf.o users do not need it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-28core.abbrevguard: Ensure short object names stay unique a bit longerLibravatar Junio C Hamano1-1/+3
Even though git makes sure that it uses enough hexdigits to show an abbreviated object name unambiguously, as more objects are added to the repository over time, a short name that used to be unique will stop being unique. Git uses this many extra hexdigits that are more than necessary to make the object name currently unique, in the hope that its output will stay unique a bit longer. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29blame,cat-file --textconv: Don't assume mode is ``S_IFREF | 0664''Libravatar Kirill Smelkov1-0/+2
We need to get the correct mode when blame reads the source from the working tree, the index, or trees. This allows us to omit running textconv filters on symbolic links. Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru> Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-27update comment and documentation for :/foo syntaxLibravatar Matthieu Moy1-0/+1
The documentation in revisions.txt did not match the implementation, and the comment in sha1_name.c was incomplete. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-03Merge branch 'js/maint-reflog-beyond-horizon'Libravatar Junio C Hamano1-9/+9
* js/maint-reflog-beyond-horizon: t1503: fix broken test_must_fail calls rev-parse: tests git rev-parse --verify master@{n}, for various n sha1_name.c: use warning in preference to fprintf(stderr rev-parse: exit with non-zero status if ref@{n} is not valid.
2010-08-24sha1_name.c: use warning in preference to fprintf(stderrLibravatar Jon Seymour1-5/+4
This commit changes sha1_name.c to use warning instead of fprintf(stderr). Trailing newlines from message formats have been removed since warning adds one itself. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-24rev-parse: exit with non-zero status if ref@{n} is not valid.Libravatar Jon Seymour1-4/+5
"The current behaviour of ref@{...} syntax parser is suboptimal: $ git rev-parse --verify jch@{99999} && echo true warning: Log for 'jch' only has 1368 entries. cfb88e9a8d4926b0011ae2dd67e1f57a98f4b768 true It even knows that it is running off the cut-off point; it should just cause the caller to notice that fact. I don't think changing it to error out should cause any harm to existing callers." With this change: $ git rev-parse --verify jch@{99999} || echo false fatal: Log for 'jch' only has 1368 entries. false $ git rev-parse jch@{99999} || echo false fatal: Log for 'jch' only has 1368 entries. false Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-19Merge branch 'jc/sha1-name-find-fix' into maintLibravatar Junio C Hamano1-10/+11
* jc/sha1-name-find-fix: sha1_name.c: fix parsing of ":/token" syntax Conflicts: sha1_name.c
2010-08-12Merge branch 'jc/sha1-name-find-fix'Libravatar Junio C Hamano1-10/+11
* jc/sha1-name-find-fix: sha1_name.c: fix parsing of ":/token" syntax Conflicts: sha1_name.c
2010-08-02sha1_name.c: fix parsing of ":/token" syntaxLibravatar Junio C Hamano1-10/+11
The parser tried to clean up the object flags it used while finding commits with matching string, but was not doing a very good job at it. This caused "checkout -b new ':/token'", which internally tries to parse ':/token' twice as an object name, to fail when the commit in question was reachable from only one ref. The mask bits given to pop_most_recent_commit(&list, MASK) means "I have already been on the list to be processed, so please do not place me again even if I am found to be a parent of some other commit on the list." So mark them when we add them to the list at the beginning. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27Merge branch 'cp/textconv-cat-file'Libravatar Junio C Hamano1-5/+26
* cp/textconv-cat-file: git-cat-file.txt: Document --textconv t/t8007: test textconv support for cat-file textconv: support for cat_file sha1_name: add get_sha1_with_context()
2010-06-18sha1_name: add get_sha1_with_context()Libravatar Clément Poulain1-5/+26
Textconv is defined by the diff driver, which is associated with a pathname, not a blob. This fonction permits to know the context for the sha1 you're looking for, especially his pathname Signed-off-by: Clément Poulain <clement.poulain@ensimag.imag.fr> Signed-off-by: Diane Gasselin <diane.gasselin@ensimag.imag.fr> Signed-off-by: Axel Bonnet <axel.bonnet@ensimag.imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-14Make :/ accept a regex rather than a fixed patternLibravatar Linus Torvalds1-3/+9
This also makes it trigger anywhere in the commit message, rather than just at the beginning. Which tends to be a lot more useful. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-28sha1_name: fix segfault caused by invalid index accessLibravatar Markus Heidelberg1-14/+18
The code to see if user input "git show :path" makes sense tried to access the index without properly checking the array bound. Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-16Merge branch 'maint-1.6.6' into maintLibravatar Junio C Hamano1-2/+1
* maint-1.6.6: dwim_ref: fix dangling symref warning stash pop: remove 'apply' options during 'drop' invocation diff: make sure --output=/bad/path is caught Remove hyphen from "git-command" in two error messages
2010-02-16Merge branch 'maint-1.6.5' into maint-1.6.6Libravatar Junio C Hamano1-2/+1
* maint-1.6.5: dwim_ref: fix dangling symref warning stash pop: remove 'apply' options during 'drop' invocation diff: make sure --output=/bad/path is caught
2010-02-16dwim_ref: fix dangling symref warningLibravatar Jeff King1-2/+1
If we encounter a symref that is dangling, in most cases we will warn about it. The one exception is a dangling HEAD, as that indicates a branch yet to be born. However, the check in dwim_ref was not quite right. If we were fed something like "HEAD^0" we would try to resolve "HEAD", see that it is dangling, and then check whether the _original_ string we got was "HEAD" (which it wasn't in this case). And that makes no sense; the dangling thing we found was not "HEAD^0" but rather "HEAD". Fixing this squelches a scary warning from "submodule summary HEAD" (and consequently "git status" with status.submodulesummary set) in an empty repo, as the submodule script calls "git rev-parse -q --verify HEAD^0". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-28reject @{-1} not at beginning of object nameLibravatar Jeff King1-0/+4
Something like foo@{-1} is nonsensical, as the @{-N} syntax is reserved for "the Nth last branch", and is not an actual reflog selector. We should not feed such nonsense to approxidate at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-28fix parsing of @{-1}@{u} combinationLibravatar Jeff King1-2/+22
Previously interpret_branch_name would see @{-1} and stop parsing, leaving the @{u} as cruft that provoked an error. Instead, we should recurse if there is more to parse. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-27Merge branch 'jc/maint-reflog-bad-timestamp'Libravatar Junio C Hamano1-1/+4
* jc/maint-reflog-bad-timestamp: t0101: use a fixed timestamp when searching in the reflog Update @{bogus.timestamp} fix not to die() approxidate_careful() reports errorneous date string
2010-01-27Update @{bogus.timestamp} fix not to die()Libravatar Junio C Hamano1-2/+2
The caller will say "It is not a valid object name" if it wants to, and some callers may even try to see if it names an object and otherwise try to see if it is a path. Pointed out by Jeff King. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-26approxidate_careful() reports errorneous date stringLibravatar Junio C Hamano1-1/+4
For a long time, the time based reflog syntax (e.g. master@{yesterday}) didn't complain when the "human readable" timestamp was misspelled, as the underlying mechanism tried to be as lenient as possible. The funny thing was that parsing of "@{now}" even relied on the fact that anything not recognized by the machinery returned the current timestamp. Introduce approxidate_careful() that takes an optional pointer to an integer, that gets assigned 1 when the input does not make sense as a timestamp. As I am too lazy to fix all the callers that use approxidate(), most of the callers do not take advantage of the error checking, but convert the code to parse reflog to use it as a demonstration. Tests are mostly from Jeff King. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-22Merge branch 'js/refer-upstream'Libravatar Junio C Hamano1-13/+78
* js/refer-upstream: Teach @{upstream} syntax to strbuf_branchanme() t1506: more test for @{upstream} syntax Introduce <branch>@{upstream} notation
2010-01-20Teach @{upstream} syntax to strbuf_branchanme()Libravatar Junio C Hamano1-42/+74
This teaches @{upstream} syntax to interpret_branch_name(), instead of dwim_ref() machinery. There are places in git UI that behaves differently when you give a local branch name and when you give an extended SHA-1 expression that evaluates to the commit object name at the tip of the branch. The intent is that the special syntax such as @{-1} can stand in as if the user spelled the name of the branch in such places. The name of the branch "frotz" to switch to ("git checkout frotz"), and the name of the branch "nitfol" to fork a new branch "frotz" from ("git checkout -b frotz nitfol"), are examples of such places. These places take only the name of the branch (e.g. "frotz"), and they are supposed to act differently to an equivalent refname (e.g. "refs/heads/frotz"), so hooking the @{upstream} and @{-N} syntax to dwim_ref() is insufficient when we want to deal with cases a local branch is forked from another local branch and use "forked@{upstream}" to name the forkee branch. The "upstream" syntax "forked@{u}" is to specify the ref that "forked" is configured to merge with, and most often the forkee is a remote tracking branch, not a local branch. We cannot simply return a local branch name, but that does not necessarily mean we have to returns the full refname (e.g. refs/remotes/origin/frotz, when returning origin/frotz is enough). This update calls shorten_unambiguous_ref() to do so. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-13Merge branch 'jc/checkout-merge-base'Libravatar Junio C Hamano1-0/+42
* jc/checkout-merge-base: rebase -i: teach --onto A...B syntax rebase: fix --onto A...B parsing and add tests "rebase --onto A...B" replays history on the merge base between A and B "checkout A...B" switches to the merge base between A and B
2010-01-12Introduce <branch>@{upstream} notationLibravatar Johannes Schindelin1-3/+36
A new notation '<branch>@{upstream}' refers to the branch <branch> is set to build on top of. Missing <branch> (i.e. '@{upstream}') defaults to the current branch. This allows you to run, for example, for l in list of local branches do git log --oneline --left-right $l...$l@{upstream} done to inspect each of the local branches you are interested in for the divergence from its upstream. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-07Detailed diagnosis when parsing an object name fails.Libravatar Matthieu Moy1-4/+111
The previous error message was the same in many situations (unknown revision or path not in the working tree). We try to help the user as much as possible to understand the error, especially with the sha1:filename notation. In this case, we say whether the sha1 or the filename is problematic, and diagnose the confusion between relative-to-root and relative-to-$PWD confusion precisely. The 7 new error messages are tested. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-18"checkout A...B" switches to the merge base between A and BLibravatar Junio C Hamano1-0/+42
When flipping commits around on topic branches, I often end up doing this sequence: * Run "log --oneline next..jc/frotz" to find out the first commit on 'jc/frotz' branch not yet merged to 'next'; * Run "checkout $that_commit^" to detach HEAD to the parent of it; * Rebuild the series on top of that commit; and * "show-branch jc/frotz HEAD" and "diff jc/frotz HEAD" to verify. Introduce a new syntax to "git checkout" to name the commit to switch to, to make the first two steps easier. When the branch to switch to is specified as A...B (you can omit either A or B but not both, and HEAD is used instead of the omitted side), the merge base between these two commits are computed, and if there is one unique one, we detach the HEAD at that commit. With this, I can say "checkout next...jc/frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-16sha1_name.c: avoid unnecessary strbuf_releaseLibravatar Brandon Casey1-2/+0
When we fall back to a standard for_each_reflog_ent() after failing to find the nth branch switch (or if we had a short reflog) with the call to for_each_recent_reflog_ent(), we do not need to free the memory allocated for our strbuf's since a strbuf_reset() will be performed in grab_nth_branch_switch() before assigning to the entry. Plus, the strbuf_release() negates the non-zero hint we initially gave to strbuf_init() just above these lines. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22Rename interpret/substitute nth_last_branch functionsLibravatar Junio C Hamano1-6/+6
These allow you to say "git checkout @{-2}" to switch to the branch two "branch switching" ago by pretending as if you typed the name of that branch. As it is likely that we will be introducing more short-hands to write the name of a branch without writing it explicitly, rename the functions from "nth_last_branch" to more generic "branch_name", to prepare for different semantics. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11Squelch overzealous "ignoring dangling symref" in an empty repositoryLibravatar Junio C Hamano1-1/+2
057e713 (Warn use of "origin" when remotes/origin/HEAD is dangling, 2009-02-08) tried to warn dangling refs/remotes/origin/HEAD only when "origin" was used to refer to it. There was one corner case a symref is expected to be dangling and this warning is unwarranted: HEAD in an empty repository. This squelches the warning for this special case. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-10Warn use of "origin" when remotes/origin/HEAD is danglingLibravatar Junio C Hamano1-2/+4
The previous one squelched the diagnositic message we used to issue every time we enumerated the refs and noticed a dangling ref. This adds the warning back to the place where the user actually attempts to use it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-28Merge branch 'tr/previous-branch'Libravatar Junio C Hamano1-4/+123
* tr/previous-branch: t1505: remove debugging cruft Simplify parsing branch switching events in reflog Introduce for_each_recent_reflog_ent(). interpret_nth_last_branch(): plug small memleak Fix reflog parsing for a malformed branch switching entry Fix parsing of @{-1}@{1} interpret_nth_last_branch(): avoid traversing the reflog twice checkout: implement "-" abbreviation, add docs and tests sha1_name: support @{-N} syntax in get_sha1() sha1_name: tweak @{-N} lookup checkout: implement "@{-N}" shortcut name for N-th last branch Conflicts: sha1_name.c
2009-01-27Merge branch 'maint-1.6.0' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.6.0: test-path-utils: Fix off by one, found by valgrind get_sha1_basic(): fix invalid memory access, found by valgrind
2009-01-27get_sha1_basic(): fix invalid memory access, found by valgrindLibravatar Johannes Schindelin1-1/+1
When get_sha1_basic() is passed a buffer of len 0, it should not check if buf[len-1] is a curly bracket. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>