summaryrefslogtreecommitdiff
path: root/sha1_name.c
AgeCommit message (Collapse)AuthorFilesLines
2007-02-08reflog: handle $name => remotes/%s/HEAD mapping consistently for logsLibravatar Junio C Hamano1-8/+21
When refs/remotes/gfi/master and refs/remotes/gfi/HEAD exist, and the latter is a symref that points at the former, dwim_ref() resolves string "gfi" to "refs/remotes/gfi/master" as expected, but dwim_log() does not understand "gfi@{1.day}" and needs to be told "gfi/master@{1.day}". This is confusing. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-08log --reflog: use dwim_logLibravatar Johannes Schindelin1-1/+1
Since "git log origin/master" uses dwim_log() to match "refs/remotes/origin/master", it makes sense to do that for "git log --reflog", too. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Enable HEAD@{...} and make it independent from the current branchLibravatar Nicolas Pitre1-26/+36
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01provide a nice @{...} syntax to always mean the current branch reflogLibravatar Nicolas Pitre1-6/+11
This is shorter than HEAD@{...} and being nameless it has no semantic issues. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01prevent HEAD reflog to be interpreted as current branch reflogLibravatar Nicolas Pitre1-1/+15
The work in progress to enable separate reflog for HEAD will make it independent from reflog of any branch HEAD might be pointing to. In the mean time disallow HEAD@{...} until that work is completed. Otherwise people might get used to the current behavior which makes HEAD@{...} an alias for <current_branch>@{...} which won't be the case later. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19Extend read_ref_at() to be usable from places other than sha1_name.Libravatar Junio C Hamano1-1/+15
You can pass an extra argument to the function to receive the reflog message information. Also when the log does not go back beyond the point the user asked, the cut-off time and count are given back to the caller for emitting the error messages as appropriately. We could later add configuration for get_sha1_basic() to make it an error instead of it being just a warning. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19dwim_ref(): Separate name-to-ref DWIM code out.Libravatar Junio C Hamano1-14/+24
I'll be using this in another function to figure out what to pass to resolve_ref(). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-01Merge branch 'lj/refs'Libravatar Junio C Hamano1-23/+33
* lj/refs: (63 commits) Fix show-ref usagestring t3200: git-branch testsuite update sha1_name.c: avoid compilation warnings. Make git-branch a builtin ref-log: fix D/F conflict coming from deleted refs. git-revert with conflicts to behave as git-merge with conflicts core.logallrefupdates thinko-fix git-pack-refs --all core.logallrefupdates create new log file only for branch heads. Remove bashism from t3210-pack-refs.sh ref-log: allow ref@{count} syntax. pack-refs: call fflush before fsync. pack-refs: use lockfile as everybody else does. git-fetch: do not look into $GIT_DIR/refs to see if a tag exists. lock_ref_sha1_basic does not remove empty directories on BSD Do not create tag leading directories since git update-ref does it. Check that a tag exists using show-ref instead of looking for the ref file. Use git-update-ref to delete a tag instead of rm()ing the ref file. Fix refs.c;:repack_without_ref() clean-up path Clean up "git-branch.sh" and add remove recursive dir test cases. ...
2006-10-23sha1_name.c: avoid compilation warnings.Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-18Reject hexstring longer than 40-bytes in get_short_sha1()Libravatar pclouds@gmail.com1-1/+1
Such a string can never be a valid object name. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-05ref-log: allow ref@{count} syntax.Libravatar Junio C Hamano1-17/+27
Often I find myself wanting to say 'tip of "next" before I merged the last three topics'. Now I can say that with: git log next@{3}..next Since small integers alone are invalid input strings to approxidate, there is no fear of confusion. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27Merge branch 'master' into lj/refsLibravatar Junio C Hamano1-0/+26
* master: (72 commits) runstatus: do not recurse into subdirectories if not needed grep: fix --fixed-strings combined with expression. grep: free expressions and patterns when done. Corrected copy-and-paste thinko in ignore executable bit test case. An illustration of rev-list --parents --pretty=raw Allow git-checkout when on a non-existant branch. gitweb: Decode long title for link tooltips git-svn: Fix fetch --no-ignore-externals with GIT_SVN_NO_LIB=1 Ignore executable bit when adding files if filemode=0. Remove empty ref directories that prevent creating a ref. Use const for interpolate arguments git-archive: update documentation Deprecate merge-recursive.py gitweb: fix over-eager application of esc_html(). Allow '(no author)' in git-svn's authors file. Allow 'svn fetch' on '(no date)' revisions in Subversion. git-repack: allow git-repack to run in subdirectory Remove upload-tar and make git-tar-tree a thin wrapper to git-archive git-tar-tree: Move code for git-archive --format=tar to archive-tar.c git-tar-tree: Remove duplicate git_config() call ...
2006-09-20Tell between packed, unpacked and symbolic refs.Libravatar Junio C Hamano1-1/+1
This adds a "int *flag" parameter to resolve_ref() and makes for_each_ref() family to call callback function with an extra "int flag" parameter. They are used to give two bits of information (REF_ISSYMREF and REF_ISPACKED) about the ref. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-20sha1_name.c: understand "describe" output as a valid object nameLibravatar Junio C Hamano1-0/+26
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17Make ref resolution sanerLibravatar Linus Torvalds1-7/+7
The old code used to totally mix up the notion of a ref-name and the path that that ref was associated with. That was not only horribly ugly (a number of users got the path, and then wanted to try to turn it back into a ref-name again), but it fundamnetally doesn't work at all once we do any setup where a ref doesn't have a 1:1 relationship with a particular pathname. This fixes things up so that we use the ref-name throughout, and only turn it into a pathname once we actually look it up in the filesystem. That makes a lot of things much clearer and more straightforward. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-02Replace uses of strdup with xstrdup.Libravatar Shawn Pearce1-1/+1
Like xmalloc and xrealloc xstrdup dies with a useful message if the native strdup() implementation returns NULL rather than a valid pointer. I just tried to use xstrdup in new code and found it to be missing. However I expected it to be present as xmalloc and xrealloc are already commonly used throughout the code. [jc: removed the part that deals with last_XXX, which I am finding more and more dubious these days.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23Convert memset(hash,0,20) to hashclr(hash).Libravatar Junio C Hamano1-1/+1
In the same spirit as hashcmp() and hashcpy(). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23Convert memcpy(a,b,20) to hashcpy(a,b).Libravatar Shawn Pearce1-11/+11
This abstracts away the size of the hash values when copying them from memory location to memory location, much as the introduction of hashcmp abstracted away hash value comparsion. A few call sites were using char* rather than unsigned char* so I added the cast rather than open hashcpy to be void*. This is a reasonable tradeoff as most call sites already use unsigned char* and the existing hashcmp is also declared to be unsigned char*. [jc: Splitted the patch to "master" part, to be followed by a patch for merge-recursive.c which is not in "master" yet. Fixed the cast in the latter hunk to combine-diff.c which was wrong in the original. Also converted ones left-over in combine-diff.c, diff-lib.c and upload-pack.c ] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-17Do not use memcmp(sha1_1, sha1_2, 20) with hardcoded length.Libravatar David Rientjes1-3/+3
Introduces global inline: hashcmp(const unsigned char *sha1, const unsigned char *sha2) Uses memcmp for comparison and returns the result based on the length of the hash name (a future runtime decision). Acked-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-15make inline is_null_sha1 globalLibravatar David Rientjes1-1/+1
Replace sha1 comparisons to null_sha1 with a global inline (which previously an unused static inline in builtin-apply.c) [jc: with a fix from Jonas Fonseca.] Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-09find_unique_abbrev() with len=0 should not abbreviateLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-12Remove TYPE_* constant macros and use object_type enums consistently.Libravatar Linus Torvalds1-6/+6
This updates the type-enumeration constants introduced to reduce the memory footprint of "struct object" to match the type bits already used in the packfile format, by removing the former (i.e. TYPE_* constant macros) and using the latter (i.e. enum object_type) throughout the code for consistency. Eventually we can stop passing around the "type strings" entirely, and this will help - no confusion about two different integer enumeration. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24Rename safe_strncpy() to strlcpy().Libravatar Peter Eriksen1-1/+1
This cleans up the use of safe_strncpy() even more. Since it has the same semantics as strlcpy() use this name instead. Also move the definition from inside path.c to its own file compat/strlcpy.c, and use it conditionally at compile time, since some platforms already has strlcpy(). It's included in the same way as compat/setenv.c. Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-17Shrink "struct object" a bitLibravatar Linus Torvalds1-11/+11
This shrinks "struct object" by a small amount, by getting rid of the "struct type *" pointer and replacing it with a 3-bit bitfield instead. In addition, we merge the bitfields and the "flags" field, which incidentally should also remove a useless 4-byte padding from the object when in 64-bit mode. Now, our "struct object" is still too damn large, but it's now less obviously bloated, and of the remaining fields, only the "util" (which is not used by most things) is clearly something that should be eventually discarded. This shrinks the "git-rev-list --all" memory use by about 2.5% on the kernel archive (and, perhaps more importantly, on the larger mozilla archive). That may not sound like much, but I suspect it's more on a 64-bit platform. There are other remaining inefficiencies (the parent lists, for example, probably have horrible malloc overhead), but this was pretty obvious. Most of the patch is just changing the comparison of the "type" pointer from one of the constant string pointers to the appropriate new TYPE_xxx small integer constant. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-16Implement safe_strncpy() as strlcpy() and use it more.Libravatar Peter Eriksen1-2/+1
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-19Change 'master@noon' syntax to 'master@{noon}'.Libravatar Shawn Pearce1-10/+17
Its ambiguous to parse "master@2006-05-17 18:30:foo" when foo is meant as a file name and ":30" is meant as 30 minutes past 6 pm. Therefore all date specifications in a sha1 expression must now appear within brackets and the ':' splitter used for the path name in a sha1 expression ignores ':' appearing within brackets. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17Fix ref log parsing so it works properly.Libravatar Shawn Pearce1-0/+1
The log parser was only ever matching the last log record due to calling strtoul on "> 1136091609" rather than " 1136091609". Also once a match for '@' has been found after the name of the ref there is no point in looking for another '@' within the remaining text. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17Support 'master@2 hours ago' syntaxLibravatar Shawn Pearce1-17/+42
Extended sha1 expressions may now include date specifications which indicate a point in time within the local repository's history. If the ref indicated to the left of '@' has a log in $GIT_DIR/logs/<ref> then the value of the ref at the time indicated by the specification is obtained from the ref's log. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-08get_sha1() - fix infinite loop on nonexistent stage.Libravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30get_sha1(): :path and :[0-3]:path to extract from index.Libravatar Junio C Hamano1-8/+46
Earlier patch to say <ent>:<path> by Linus was very useful, and this extends the same idea to the current index. An sha1 expression :<path> extracts the object name for the named path from the current index. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19get_tree_entry(): make it available from tree-walkLibravatar Junio C Hamano1-52/+0
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19sha1_name.c: no need to include diff.h; tree-walk.h will do.Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19sha1_name.c: prepare to make get_tree_entry() reusable from others.Libravatar Junio C Hamano1-9/+10
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-18get_sha1() shorthands for blob/tree objectsLibravatar Linus Torvalds1-1/+66
This is a fairly straightforward patch to allow "get_sha1()" to also have shorthands for tree and blob objects. The syntax is very simple and intuitive: you can specify a tree or a blob by simply specifying <revision>:<path>, and get_sha1() will do the SHA1 lookup from the tree for you. You can currently do it with "git ls-tree <rev> <path>" and parsing the output, but that's actually pretty awkward. With this, you can do something like git cat-file blob v1.2.4:Makefile to get the contents of "Makefile" at revision v1.2.4. Now, this isn't necessarily something you really need all that often, but the concept itself is actually pretty powerful. We could, for example, allow things like git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh to see the difference between two arbitrary files in two arbitrary revisions. To do that, the only thing we'd have to do is to make git-diff-tree accept two blobs to diff, in addition to the two trees it now expects. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-23sha1_name: warning ambiguous refs.Libravatar Junio C Hamano1-3/+2
This makes sure that many commands that take refs on the command line to honor core.warnambiguousrefs configuration. Earlier, the commands affected by this patch did not read the configuration file. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-21get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEADLibravatar Junio C Hamano1-11/+12
This implements the suggestion by Jeff King to use refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean the primary branch head of a tracked remote. clone needs to be told about this convention as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-20core.warnambiguousrefs: warns when "name" is used and both "name" branch and ↵Libravatar Junio C Hamano1-3/+20
tag exists. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10find_unique_abbrev() simplification.Libravatar Junio C Hamano1-2/+4
Earlier it did not grok the 0{40} SHA1 very well, but what it needed to do was to find the shortest 0{N} that is not used as a valid object name to be consistent with the way names of valid objects are abbreviated. This makes some users simpler. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-02get_sha1_1: allow octopus^12 to be properly parsed.Libravatar Junio C Hamano1-23/+16
We probably thought anybody who does more than 9 parents in an Octopus is insane when this was initially done, but there is no inherent reason to limit the number of independent topic branches that happen to mature at the same time. Our commit-tree allows up to 16 already, so at least we should prepare to handle what we can produce, if only to be consistent. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28abbrev cleanup: use symbolic constantsLibravatar Junio C Hamano1-1/+1
The minimum length of abbreviated object name was hardcoded in different places to be 4, risking inconsistencies in the future. Also there were three different "default abbreviation precision". Use two C preprocessor symbols to clean up this mess. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-26Use symbolic name SHORT_NAME_AMBIGUOUS as error return valueLibravatar Uwe Zeisberger1-1/+1
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-19diff: --abbrev optionLibravatar Junio C Hamano1-0/+3
When I show transcripts to explain how something works, I often find myself hand-editing the diff-raw output to shorten various object names in the output. This adds --abbrev option to the diff family, which shortens diff-raw output and diff-tree commit id headers. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-17Revert "get_sha1_basic(): corner case ambiguity fix"Libravatar Junio C Hamano1-1/+1
This reverts 6677c4665af2d73f670bec382bc82d0f2e9513fb commit. The misguided disambiguation has been reverted, so there is no point testing that misfeature.
2005-12-17Remove misguided branch disambiguation.Libravatar Junio C Hamano1-30/+3
This removes the misguided attempt to refuse processing a branch name xyzzy and insist it to be given as either heads/xyzzy or tags/xyzzy when a tag xyzzy exists. There was no reason to do so --- the search order was predictable and well defined, so if the user says xyzzy we should have taken the tag xyzzy in such a case without complaining. This incidentally fixes another subtle bug related to this. If such a duplicate branch/tag name happened to be a unique valid prefix of an existing commit object name (say, "beef"), we did not take the tag "beef" but after complaining used the commit object whose name started with beef. Another problem this fixes while introducing some confusion is that there is no longer a reason to forbid a branch name HEAD anymore. In other words, now "git pull . ref1:HEAD" would work as expected, once we revert "We do not like HEAD branch" patch. It creates "HEAD" branch under ${GIT_DIR-.git}/refs/heads (or fast-forwards if already exists) using the tip of ref1 branch from the current repository, and merges it into the current branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-15get_sha1_basic(): corner case ambiguity fixLibravatar Junio C Hamano1-9/+26
When .git/refs/heads/frotz and .git/refs/tags/frotz existed, and the object name stored in .git/refs/heads/frotz were corrupt, we ended up picking tags/frotz without complaining. Worse yet, if the corrupt .git/refs/heads/frotz was more than 40 bytes and began with hexadecimal characters, it silently overwritten the initial part of the returned result. This commit adds a couple of tests to demonstrate these cases, with a fix. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21Make sure heads/foo and tags/foo do not confuse things.Libravatar Junio C Hamano1-3/+14
When both heads/foo and tags/foo exist, get_sha1_basic("foo") picked up the tag without complaining, which is quite confusing. Make sure we require unambiguous form, "heads/foo" or "tags/foo" in such cases. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-02Be careful when dereferencing tags.Libravatar Junio C Hamano1-1/+1
One caller of deref_tag() was not careful enough to make sure what deref_tag() returned was not NULL (i.e. we found a tag object that points at an object we do not have). Fix it, and warn about refs that point at such an incomplete tag where needed. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-28Be more careful about reference parsingLibravatar Linus Torvalds1-0/+27
This does two things: - we don't allow "." and ".." as components of a refname. Thus get_sha1() will not accept "./refname" as being the same as "refname" any more. - git-rev-parse stops doing revision translation after seeing a pathname, to match the brhaviour of all the tools (once we see a pathname, everything else will also be parsed as a pathname). Basically, if you did git log * and "gitk" was somewhere in the "*", we don't want to replace the filename "gitk" with the SHA1 of the branch with the same name. Of course, if there is any change of ambiguity, you should always use "--" to make it explicit what are filenames and what are revisions, but this makes the normal cases sane. The refname rule also means that instead of the "--", you can do the same thing we're used to doing with filenames that start with a slash: use "./filename" instead, and now it's a filename, not an option (and not a revision). So "git log ./*.c" is now actually a perfectly valid thing to do, even if the first C-file might have the same name as a branch. Trivial test: git-rev-parse gitk ./gitk gitk should output something like 9843c3074dfbf57117565f6b7c93e3e6812857ee ./gitk gitk where the "./gitk" isn't seen as a revision, and the second "gitk" is a filename simply because we've seen filenames already, and thus stopped doing revision parsing. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19Make sure we barf on ref^{type} failure.Libravatar Junio C Hamano1-1/+3
Martin Langhoff noticed that ref^0 barfed correctly when we did not have the commit in a broken repository, but ref^{commit} didn't. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15Introduce notation "ref^{type}".Libravatar Junio C Hamano1-0/+83
Existing "tagname^0" notation means "dereference tag zero or more times until you cannot dereference it anymore, and make sure it is a commit -- otherwise barf". But tags do not necessarily reference commit objects. This commit introduces a bit more generalized notation, "ref^{type}". Existing "ref^0" is a shorthand for "ref^{commit}". If the type is empty, it just dereferences tags until it hits a non-tag object. With this, "git-rev-parse --verify 'junio-gpg-pub^{}'" shows the blob object name -- there is no need to manually read the tag object and find out the object name anymore. "git-rev-parse --verify 'HEAD^{tree}'" can be used to find out the tree object name of the HEAD commit. Signed-off-by: Junio C Hamano <junkio@cox.net>