2005-08-04 09:15:49 +04:00
|
|
|
#include "cache.h"
|
2005-10-14 05:57:40 +04:00
|
|
|
#include "tag.h"
|
2005-08-04 09:15:49 +04:00
|
|
|
#include "commit.h"
|
2005-10-14 05:57:40 +04:00
|
|
|
#include "tree.h"
|
|
|
|
#include "blob.h"
|
2006-04-19 22:56:53 +04:00
|
|
|
#include "tree-walk.h"
|
2006-05-17 13:56:09 +04:00
|
|
|
#include "refs.h"
|
2005-08-04 09:15:49 +04:00
|
|
|
|
|
|
|
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
|
|
|
|
{
|
2005-10-03 08:40:51 +04:00
|
|
|
struct alternate_object_database *alt;
|
2005-08-04 09:15:49 +04:00
|
|
|
char hex[40];
|
2005-10-03 08:40:51 +04:00
|
|
|
int found = 0;
|
|
|
|
static struct alternate_object_database *fakeent;
|
|
|
|
|
|
|
|
if (!fakeent) {
|
|
|
|
const char *objdir = get_object_directory();
|
|
|
|
int objdir_len = strlen(objdir);
|
|
|
|
int entlen = objdir_len + 43;
|
|
|
|
fakeent = xmalloc(sizeof(*fakeent) + entlen);
|
|
|
|
memcpy(fakeent->base, objdir, objdir_len);
|
|
|
|
fakeent->name = fakeent->base + objdir_len + 1;
|
|
|
|
fakeent->name[-1] = '/';
|
|
|
|
}
|
|
|
|
fakeent->next = alt_odb_list;
|
2005-08-04 09:15:49 +04:00
|
|
|
|
|
|
|
sprintf(hex, "%.2s", name);
|
2005-10-03 08:40:51 +04:00
|
|
|
for (alt = fakeent; alt && found < 2; alt = alt->next) {
|
2005-08-04 09:15:49 +04:00
|
|
|
struct dirent *de;
|
2005-10-03 08:40:51 +04:00
|
|
|
DIR *dir;
|
|
|
|
sprintf(alt->name, "%.2s/", name);
|
|
|
|
dir = opendir(alt->base);
|
|
|
|
if (!dir)
|
|
|
|
continue;
|
2005-08-04 09:15:49 +04:00
|
|
|
while ((de = readdir(dir)) != NULL) {
|
|
|
|
if (strlen(de->d_name) != 38)
|
|
|
|
continue;
|
2005-10-03 08:40:51 +04:00
|
|
|
if (memcmp(de->d_name, name + 2, len - 2))
|
2005-08-04 09:15:49 +04:00
|
|
|
continue;
|
2005-10-03 08:40:51 +04:00
|
|
|
if (!found) {
|
|
|
|
memcpy(hex + 2, de->d_name, 38);
|
|
|
|
found++;
|
|
|
|
}
|
|
|
|
else if (memcmp(hex + 2, de->d_name, 38)) {
|
|
|
|
found = 2;
|
2005-08-04 09:15:49 +04:00
|
|
|
break;
|
2005-10-03 08:40:51 +04:00
|
|
|
}
|
2005-08-04 09:15:49 +04:00
|
|
|
}
|
|
|
|
closedir(dir);
|
|
|
|
}
|
|
|
|
if (found == 1)
|
|
|
|
return get_sha1_hex(hex, sha1) == 0;
|
2005-10-03 08:40:51 +04:00
|
|
|
return found;
|
2005-08-04 09:15:49 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static int match_sha(unsigned len, const unsigned char *a, const unsigned char *b)
|
|
|
|
{
|
|
|
|
do {
|
|
|
|
if (*a != *b)
|
|
|
|
return 0;
|
|
|
|
a++;
|
|
|
|
b++;
|
|
|
|
len -= 2;
|
|
|
|
} while (len > 1);
|
|
|
|
if (len)
|
|
|
|
if ((*a ^ *b) & 0xf0)
|
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int find_short_packed_object(int len, const unsigned char *match, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
struct packed_git *p;
|
2005-10-03 08:40:51 +04:00
|
|
|
unsigned char found_sha1[20];
|
|
|
|
int found = 0;
|
2005-08-04 09:15:49 +04:00
|
|
|
|
|
|
|
prepare_packed_git();
|
2005-10-03 08:40:51 +04:00
|
|
|
for (p = packed_git; p && found < 2; p = p->next) {
|
2005-08-04 09:15:49 +04:00
|
|
|
unsigned num = num_packed_objects(p);
|
|
|
|
unsigned first = 0, last = num;
|
|
|
|
while (first < last) {
|
|
|
|
unsigned mid = (first + last) / 2;
|
|
|
|
unsigned char now[20];
|
|
|
|
int cmp;
|
|
|
|
|
|
|
|
nth_packed_object_sha1(p, mid, now);
|
|
|
|
cmp = memcmp(match, now, 20);
|
|
|
|
if (!cmp) {
|
|
|
|
first = mid;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (cmp > 0) {
|
|
|
|
first = mid+1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
last = mid;
|
|
|
|
}
|
|
|
|
if (first < num) {
|
2005-10-03 08:40:51 +04:00
|
|
|
unsigned char now[20], next[20];
|
2005-08-04 09:15:49 +04:00
|
|
|
nth_packed_object_sha1(p, first, now);
|
|
|
|
if (match_sha(len, match, now)) {
|
2005-10-03 08:40:51 +04:00
|
|
|
if (nth_packed_object_sha1(p, first+1, next) ||
|
|
|
|
!match_sha(len, match, next)) {
|
|
|
|
/* unique within this pack */
|
|
|
|
if (!found) {
|
|
|
|
memcpy(found_sha1, now, 20);
|
|
|
|
found++;
|
|
|
|
}
|
|
|
|
else if (memcmp(found_sha1, now, 20)) {
|
|
|
|
found = 2;
|
|
|
|
break;
|
|
|
|
}
|
2005-10-03 08:40:51 +04:00
|
|
|
}
|
2005-10-03 08:40:51 +04:00
|
|
|
else {
|
|
|
|
/* not even unique within this pack */
|
2005-10-03 08:40:51 +04:00
|
|
|
found = 2;
|
|
|
|
break;
|
2005-08-04 09:15:49 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2005-10-03 08:40:51 +04:00
|
|
|
if (found == 1)
|
|
|
|
memcpy(sha1, found_sha1, 20);
|
|
|
|
return found;
|
|
|
|
}
|
|
|
|
|
2005-10-12 02:22:48 +04:00
|
|
|
#define SHORT_NAME_NOT_FOUND (-1)
|
|
|
|
#define SHORT_NAME_AMBIGUOUS (-2)
|
|
|
|
|
2005-10-03 08:40:51 +04:00
|
|
|
static int find_unique_short_object(int len, char *canonical,
|
|
|
|
unsigned char *res, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
int has_unpacked, has_packed;
|
|
|
|
unsigned char unpacked_sha1[20], packed_sha1[20];
|
|
|
|
|
|
|
|
has_unpacked = find_short_object_filename(len, canonical, unpacked_sha1);
|
|
|
|
has_packed = find_short_packed_object(len, res, packed_sha1);
|
|
|
|
if (!has_unpacked && !has_packed)
|
2005-10-12 02:22:48 +04:00
|
|
|
return SHORT_NAME_NOT_FOUND;
|
2005-10-03 08:40:51 +04:00
|
|
|
if (1 < has_unpacked || 1 < has_packed)
|
2005-10-12 02:22:48 +04:00
|
|
|
return SHORT_NAME_AMBIGUOUS;
|
2005-10-03 08:40:51 +04:00
|
|
|
if (has_unpacked != has_packed) {
|
|
|
|
memcpy(sha1, (has_packed ? packed_sha1 : unpacked_sha1), 20);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
/* Both have unique ones -- do they match? */
|
|
|
|
if (memcmp(packed_sha1, unpacked_sha1, 20))
|
2006-01-26 14:26:15 +03:00
|
|
|
return SHORT_NAME_AMBIGUOUS;
|
2005-10-03 08:40:51 +04:00
|
|
|
memcpy(sha1, packed_sha1, 20);
|
2005-08-04 09:15:49 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-10-12 02:22:48 +04:00
|
|
|
static int get_short_sha1(const char *name, int len, unsigned char *sha1,
|
|
|
|
int quietly)
|
2005-08-04 09:15:49 +04:00
|
|
|
{
|
2005-10-12 02:22:48 +04:00
|
|
|
int i, status;
|
2005-08-04 09:15:49 +04:00
|
|
|
char canonical[40];
|
|
|
|
unsigned char res[20];
|
|
|
|
|
2006-01-25 12:03:18 +03:00
|
|
|
if (len < MINIMUM_ABBREV)
|
2005-09-20 02:16:03 +04:00
|
|
|
return -1;
|
2005-08-04 09:15:49 +04:00
|
|
|
memset(res, 0, 20);
|
|
|
|
memset(canonical, 'x', 40);
|
2005-09-20 02:16:03 +04:00
|
|
|
for (i = 0; i < len ;i++) {
|
2005-08-04 09:15:49 +04:00
|
|
|
unsigned char c = name[i];
|
|
|
|
unsigned char val;
|
|
|
|
if (c >= '0' && c <= '9')
|
|
|
|
val = c - '0';
|
|
|
|
else if (c >= 'a' && c <= 'f')
|
|
|
|
val = c - 'a' + 10;
|
|
|
|
else if (c >= 'A' && c <='F') {
|
|
|
|
val = c - 'A' + 10;
|
|
|
|
c -= 'A' - 'a';
|
|
|
|
}
|
|
|
|
else
|
|
|
|
return -1;
|
|
|
|
canonical[i] = c;
|
|
|
|
if (!(i & 1))
|
|
|
|
val <<= 4;
|
|
|
|
res[i >> 1] |= val;
|
|
|
|
}
|
2005-10-03 08:40:51 +04:00
|
|
|
|
2005-10-12 02:22:48 +04:00
|
|
|
status = find_unique_short_object(i, canonical, res, sha1);
|
|
|
|
if (!quietly && (status == SHORT_NAME_AMBIGUOUS))
|
|
|
|
return error("short SHA1 %.*s is ambiguous.", len, canonical);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *find_unique_abbrev(const unsigned char *sha1, int len)
|
|
|
|
{
|
2006-02-10 12:51:12 +03:00
|
|
|
int status, is_null;
|
2005-10-12 02:22:48 +04:00
|
|
|
static char hex[41];
|
2005-12-14 04:21:41 +03:00
|
|
|
|
2006-02-10 12:51:12 +03:00
|
|
|
is_null = !memcmp(sha1, null_sha1, 20);
|
2005-10-12 02:22:48 +04:00
|
|
|
memcpy(hex, sha1_to_hex(sha1), 40);
|
2005-12-14 04:21:41 +03:00
|
|
|
if (len == 40)
|
|
|
|
return hex;
|
2005-10-12 02:22:48 +04:00
|
|
|
while (len < 40) {
|
|
|
|
unsigned char sha1_ret[20];
|
|
|
|
status = get_short_sha1(hex, len, sha1_ret, 1);
|
2006-02-10 12:51:12 +03:00
|
|
|
if (!status ||
|
|
|
|
(is_null && status != SHORT_NAME_AMBIGUOUS)) {
|
2005-10-12 02:22:48 +04:00
|
|
|
hex[len] = 0;
|
|
|
|
return hex;
|
|
|
|
}
|
|
|
|
if (status != SHORT_NAME_AMBIGUOUS)
|
|
|
|
return NULL;
|
|
|
|
len++;
|
|
|
|
}
|
|
|
|
return NULL;
|
2005-08-04 09:15:49 +04:00
|
|
|
}
|
|
|
|
|
2005-12-15 23:54:00 +03:00
|
|
|
static int ambiguous_path(const char *path, int len)
|
Be more careful about reference parsing
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-28 23:41:49 +04:00
|
|
|
{
|
|
|
|
int slash = 1;
|
2005-12-15 23:54:00 +03:00
|
|
|
int cnt;
|
Be more careful about reference parsing
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-28 23:41:49 +04:00
|
|
|
|
2005-12-15 23:54:00 +03:00
|
|
|
for (cnt = 0; cnt < len; cnt++) {
|
Be more careful about reference parsing
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-28 23:41:49 +04:00
|
|
|
switch (*path++) {
|
|
|
|
case '\0':
|
|
|
|
break;
|
|
|
|
case '/':
|
|
|
|
if (slash)
|
|
|
|
break;
|
|
|
|
slash = 1;
|
|
|
|
continue;
|
|
|
|
case '.':
|
|
|
|
continue;
|
|
|
|
default:
|
|
|
|
slash = 0;
|
|
|
|
continue;
|
|
|
|
}
|
2005-12-17 11:00:50 +03:00
|
|
|
break;
|
Be more careful about reference parsing
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-28 23:41:49 +04:00
|
|
|
}
|
2005-12-15 23:54:00 +03:00
|
|
|
return slash;
|
Be more careful about reference parsing
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-28 23:41:49 +04:00
|
|
|
}
|
|
|
|
|
2005-08-04 09:15:49 +04:00
|
|
|
static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
|
|
|
|
{
|
2006-03-21 12:42:04 +03:00
|
|
|
static const char *fmt[] = {
|
2006-03-24 10:41:18 +03:00
|
|
|
"%.*s",
|
2006-03-21 12:42:04 +03:00
|
|
|
"refs/%.*s",
|
|
|
|
"refs/tags/%.*s",
|
|
|
|
"refs/heads/%.*s",
|
|
|
|
"refs/remotes/%.*s",
|
|
|
|
"refs/remotes/%.*s/HEAD",
|
2005-08-04 09:15:49 +04:00
|
|
|
NULL
|
|
|
|
};
|
2006-05-17 13:56:09 +04:00
|
|
|
static const char *warning = "warning: refname '%.*s' is ambiguous.\n";
|
|
|
|
const char **p, *pathname;
|
|
|
|
char *real_path = NULL;
|
2006-05-19 11:29:43 +04:00
|
|
|
int refs_found = 0, am;
|
2006-05-17 13:56:09 +04:00
|
|
|
unsigned long at_time = (unsigned long)-1;
|
2006-03-21 12:42:04 +03:00
|
|
|
unsigned char *this_result;
|
|
|
|
unsigned char sha1_from_ref[20];
|
2005-08-04 09:15:49 +04:00
|
|
|
|
2005-08-13 22:05:25 +04:00
|
|
|
if (len == 40 && !get_sha1_hex(str, sha1))
|
2005-08-04 09:15:49 +04:00
|
|
|
return 0;
|
|
|
|
|
2006-05-19 11:29:43 +04:00
|
|
|
/* At a given period of time? "@{2 hours ago}" */
|
|
|
|
for (am = 1; am < len - 1; am++) {
|
|
|
|
if (str[am] == '@' && str[am+1] == '{' && str[len-1] == '}') {
|
|
|
|
int date_len = len - am - 3;
|
2006-05-17 13:56:09 +04:00
|
|
|
char *date_spec = xmalloc(date_len + 1);
|
2006-06-24 18:01:25 +04:00
|
|
|
strlcpy(date_spec, str + am + 2, date_len + 1);
|
2006-05-17 13:56:09 +04:00
|
|
|
at_time = approxidate(date_spec);
|
|
|
|
free(date_spec);
|
2006-05-19 11:29:43 +04:00
|
|
|
len = am;
|
2006-05-18 02:34:48 +04:00
|
|
|
break;
|
2006-05-17 13:56:09 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Be more careful about reference parsing
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-28 23:41:49 +04:00
|
|
|
/* Accept only unambiguous ref paths. */
|
2005-12-15 23:54:00 +03:00
|
|
|
if (ambiguous_path(str, len))
|
Be more careful about reference parsing
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-28 23:41:49 +04:00
|
|
|
return -1;
|
|
|
|
|
2006-03-21 12:42:04 +03:00
|
|
|
for (p = fmt; *p; p++) {
|
2006-05-17 13:56:09 +04:00
|
|
|
this_result = refs_found ? sha1_from_ref : sha1;
|
|
|
|
pathname = resolve_ref(git_path(*p, len, str), this_result, 1);
|
|
|
|
if (pathname) {
|
|
|
|
if (!refs_found++)
|
|
|
|
real_path = strdup(pathname);
|
|
|
|
if (!warn_ambiguous_refs)
|
|
|
|
break;
|
2006-03-21 05:45:47 +03:00
|
|
|
}
|
2005-12-15 23:54:00 +03:00
|
|
|
}
|
2006-05-17 13:56:09 +04:00
|
|
|
|
|
|
|
if (!refs_found)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (warn_ambiguous_refs && refs_found > 1)
|
|
|
|
fprintf(stderr, warning, len, str);
|
|
|
|
|
|
|
|
if (at_time != (unsigned long)-1) {
|
|
|
|
read_ref_at(
|
|
|
|
real_path + strlen(git_path(".")) - 1,
|
|
|
|
at_time,
|
|
|
|
sha1);
|
|
|
|
}
|
|
|
|
|
|
|
|
free(real_path);
|
|
|
|
return 0;
|
2005-08-04 09:15:49 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static int get_sha1_1(const char *name, int len, unsigned char *sha1);
|
|
|
|
|
|
|
|
static int get_parent(const char *name, int len,
|
|
|
|
unsigned char *result, int idx)
|
|
|
|
{
|
|
|
|
unsigned char sha1[20];
|
|
|
|
int ret = get_sha1_1(name, len, sha1);
|
|
|
|
struct commit *commit;
|
|
|
|
struct commit_list *p;
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
commit = lookup_commit_reference(sha1);
|
|
|
|
if (!commit)
|
|
|
|
return -1;
|
|
|
|
if (parse_commit(commit))
|
|
|
|
return -1;
|
|
|
|
if (!idx) {
|
|
|
|
memcpy(result, commit->object.sha1, 20);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
p = commit->parents;
|
|
|
|
while (p) {
|
|
|
|
if (!--idx) {
|
|
|
|
memcpy(result, p->item->object.sha1, 20);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
p = p->next;
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2005-08-21 13:43:54 +04:00
|
|
|
static int get_nth_ancestor(const char *name, int len,
|
|
|
|
unsigned char *result, int generation)
|
|
|
|
{
|
|
|
|
unsigned char sha1[20];
|
|
|
|
int ret = get_sha1_1(name, len, sha1);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
while (generation--) {
|
|
|
|
struct commit *commit = lookup_commit_reference(sha1);
|
|
|
|
|
|
|
|
if (!commit || parse_commit(commit) || !commit->parents)
|
|
|
|
return -1;
|
|
|
|
memcpy(sha1, commit->parents->item->object.sha1, 20);
|
|
|
|
}
|
|
|
|
memcpy(result, sha1, 20);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-10-14 05:57:40 +04:00
|
|
|
static int peel_onion(const char *name, int len, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
unsigned char outer[20];
|
|
|
|
const char *sp;
|
Shrink "struct object" a bit
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-15 03:45:13 +04:00
|
|
|
unsigned int expected_type = 0;
|
2005-10-14 05:57:40 +04:00
|
|
|
struct object *o;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* "ref^{type}" dereferences ref repeatedly until you cannot
|
|
|
|
* dereference anymore, or you get an object of given type,
|
|
|
|
* whichever comes first. "ref^{}" means just dereference
|
|
|
|
* tags until you get a non-tag. "ref^0" is a shorthand for
|
|
|
|
* "ref^{commit}". "commit^{tree}" could be used to find the
|
|
|
|
* top-level tree of the given commit.
|
|
|
|
*/
|
|
|
|
if (len < 4 || name[len-1] != '}')
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
for (sp = name + len - 1; name <= sp; sp--) {
|
|
|
|
int ch = *sp;
|
|
|
|
if (ch == '{' && name < sp && sp[-1] == '^')
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (sp <= name)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
sp++; /* beginning of type name, or closing brace for empty */
|
|
|
|
if (!strncmp(commit_type, sp, 6) && sp[6] == '}')
|
Shrink "struct object" a bit
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-15 03:45:13 +04:00
|
|
|
expected_type = TYPE_COMMIT;
|
2005-10-14 05:57:40 +04:00
|
|
|
else if (!strncmp(tree_type, sp, 4) && sp[4] == '}')
|
Shrink "struct object" a bit
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-15 03:45:13 +04:00
|
|
|
expected_type = TYPE_TREE;
|
2005-10-14 05:57:40 +04:00
|
|
|
else if (!strncmp(blob_type, sp, 4) && sp[4] == '}')
|
Shrink "struct object" a bit
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-15 03:45:13 +04:00
|
|
|
expected_type = TYPE_BLOB;
|
2005-10-14 05:57:40 +04:00
|
|
|
else if (sp[0] == '}')
|
Shrink "struct object" a bit
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-15 03:45:13 +04:00
|
|
|
expected_type = TYPE_NONE;
|
2005-10-14 05:57:40 +04:00
|
|
|
else
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (get_sha1_1(name, sp - name - 2, outer))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
o = parse_object(outer);
|
|
|
|
if (!o)
|
|
|
|
return -1;
|
Shrink "struct object" a bit
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-15 03:45:13 +04:00
|
|
|
if (!expected_type) {
|
2005-11-03 02:19:13 +03:00
|
|
|
o = deref_tag(o, name, sp - name - 2);
|
2005-10-20 09:48:16 +04:00
|
|
|
if (!o || (!o->parsed && !parse_object(o->sha1)))
|
|
|
|
return -1;
|
2005-10-14 05:57:40 +04:00
|
|
|
memcpy(sha1, o->sha1, 20);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* At this point, the syntax look correct, so
|
|
|
|
* if we do not get the needed object, we should
|
|
|
|
* barf.
|
|
|
|
*/
|
|
|
|
|
|
|
|
while (1) {
|
2005-10-20 09:48:16 +04:00
|
|
|
if (!o || (!o->parsed && !parse_object(o->sha1)))
|
2005-10-14 05:57:40 +04:00
|
|
|
return -1;
|
Shrink "struct object" a bit
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-15 03:45:13 +04:00
|
|
|
if (o->type == expected_type) {
|
2005-10-14 05:57:40 +04:00
|
|
|
memcpy(sha1, o->sha1, 20);
|
|
|
|
return 0;
|
|
|
|
}
|
Shrink "struct object" a bit
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-15 03:45:13 +04:00
|
|
|
if (o->type == TYPE_TAG)
|
2005-10-14 05:57:40 +04:00
|
|
|
o = ((struct tag*) o)->tagged;
|
Shrink "struct object" a bit
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-15 03:45:13 +04:00
|
|
|
else if (o->type == TYPE_COMMIT)
|
2005-10-14 05:57:40 +04:00
|
|
|
o = &(((struct commit *) o)->tree->object);
|
|
|
|
else
|
|
|
|
return error("%.*s: expected %s type, but the object dereferences to %s type",
|
Shrink "struct object" a bit
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-15 03:45:13 +04:00
|
|
|
len, name, typename(expected_type),
|
|
|
|
typename(o->type));
|
2005-10-14 05:57:40 +04:00
|
|
|
if (!o->parsed)
|
|
|
|
parse_object(o->sha1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-08-04 09:15:49 +04:00
|
|
|
static int get_sha1_1(const char *name, int len, unsigned char *sha1)
|
|
|
|
{
|
2006-02-03 10:48:36 +03:00
|
|
|
int ret, has_suffix;
|
2005-08-21 13:43:54 +04:00
|
|
|
const char *cp;
|
2005-08-04 09:15:49 +04:00
|
|
|
|
2005-08-21 13:43:54 +04:00
|
|
|
/* "name~3" is "name^^^",
|
|
|
|
* "name~" and "name~0" are name -- not "name^0"!
|
2006-02-03 10:48:36 +03:00
|
|
|
* "name^" is not "name^0"; it is "name^1".
|
2005-08-21 13:43:54 +04:00
|
|
|
*/
|
2006-02-03 10:48:36 +03:00
|
|
|
has_suffix = 0;
|
2005-08-21 13:43:54 +04:00
|
|
|
for (cp = name + len - 1; name <= cp; cp--) {
|
|
|
|
int ch = *cp;
|
|
|
|
if ('0' <= ch && ch <= '9')
|
|
|
|
continue;
|
2006-02-03 10:48:36 +03:00
|
|
|
if (ch == '~' || ch == '^')
|
|
|
|
has_suffix = ch;
|
2005-08-21 13:43:54 +04:00
|
|
|
break;
|
|
|
|
}
|
2006-02-03 10:48:36 +03:00
|
|
|
|
|
|
|
if (has_suffix) {
|
|
|
|
int num = 0;
|
2005-08-21 13:43:54 +04:00
|
|
|
int len1 = cp - name;
|
|
|
|
cp++;
|
|
|
|
while (cp < name + len)
|
2006-02-03 10:48:36 +03:00
|
|
|
num = num * 10 + *cp++ - '0';
|
|
|
|
if (has_suffix == '^') {
|
|
|
|
if (!num && len1 == len - 1)
|
|
|
|
num = 1;
|
|
|
|
return get_parent(name, len1, sha1, num);
|
|
|
|
}
|
|
|
|
/* else if (has_suffix == '~') -- goes without saying */
|
|
|
|
return get_nth_ancestor(name, len1, sha1, num);
|
2005-08-21 13:43:54 +04:00
|
|
|
}
|
|
|
|
|
2005-10-14 05:57:40 +04:00
|
|
|
ret = peel_onion(name, len, sha1);
|
|
|
|
if (!ret)
|
|
|
|
return 0;
|
|
|
|
|
2005-08-04 09:15:49 +04:00
|
|
|
ret = get_sha1_basic(name, len, sha1);
|
|
|
|
if (!ret)
|
|
|
|
return 0;
|
2005-10-12 02:22:48 +04:00
|
|
|
return get_short_sha1(name, len, sha1, 0);
|
2005-08-04 09:15:49 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is like "get_sha1_basic()", except it allows "sha1 expressions",
|
|
|
|
* notably "xyz^" for "parent of xyz"
|
|
|
|
*/
|
|
|
|
int get_sha1(const char *name, unsigned char *sha1)
|
|
|
|
{
|
2006-05-19 11:29:43 +04:00
|
|
|
int ret, bracket_depth;
|
2006-04-19 22:56:07 +04:00
|
|
|
unsigned unused;
|
2006-04-22 04:31:04 +04:00
|
|
|
int namelen = strlen(name);
|
|
|
|
const char *cp;
|
2006-04-19 03:45:16 +04:00
|
|
|
|
2005-10-03 08:40:51 +04:00
|
|
|
prepare_alt_odb();
|
2006-04-22 04:31:04 +04:00
|
|
|
ret = get_sha1_1(name, namelen, sha1);
|
|
|
|
if (!ret)
|
|
|
|
return ret;
|
|
|
|
/* sha1:path --> object name of path in ent sha1
|
|
|
|
* :path -> object name of path in index
|
|
|
|
* :[0-3]:path -> object name of path in index at stage
|
|
|
|
*/
|
|
|
|
if (name[0] == ':') {
|
|
|
|
int stage = 0;
|
|
|
|
struct cache_entry *ce;
|
|
|
|
int pos;
|
|
|
|
if (namelen < 3 ||
|
|
|
|
name[2] != ':' ||
|
|
|
|
name[1] < '0' || '3' < name[1])
|
|
|
|
cp = name + 1;
|
|
|
|
else {
|
|
|
|
stage = name[1] - '0';
|
|
|
|
cp = name + 3;
|
2006-04-19 03:45:16 +04:00
|
|
|
}
|
2006-04-22 04:31:04 +04:00
|
|
|
namelen = namelen - (cp - name);
|
|
|
|
if (!active_cache)
|
|
|
|
read_cache();
|
|
|
|
if (active_nr < 0)
|
|
|
|
return -1;
|
|
|
|
pos = cache_name_pos(cp, namelen);
|
|
|
|
if (pos < 0)
|
|
|
|
pos = -pos - 1;
|
|
|
|
while (pos < active_nr) {
|
|
|
|
ce = active_cache[pos];
|
|
|
|
if (ce_namelen(ce) != namelen ||
|
|
|
|
memcmp(ce->name, cp, namelen))
|
|
|
|
break;
|
|
|
|
if (ce_stage(ce) == stage) {
|
|
|
|
memcpy(sha1, ce->sha1, 20);
|
|
|
|
return 0;
|
|
|
|
}
|
2006-05-09 02:44:06 +04:00
|
|
|
pos++;
|
2006-04-22 04:31:04 +04:00
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
2006-05-19 11:29:43 +04:00
|
|
|
for (cp = name, bracket_depth = 0; *cp; cp++) {
|
|
|
|
if (*cp == '{')
|
|
|
|
bracket_depth++;
|
|
|
|
else if (bracket_depth && *cp == '}')
|
|
|
|
bracket_depth--;
|
|
|
|
else if (!bracket_depth && *cp == ':')
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (*cp == ':') {
|
2006-04-22 04:31:04 +04:00
|
|
|
unsigned char tree_sha1[20];
|
|
|
|
if (!get_sha1_1(name, cp-name, tree_sha1))
|
|
|
|
return get_tree_entry(tree_sha1, cp+1, sha1,
|
|
|
|
&unused);
|
2006-04-19 03:45:16 +04:00
|
|
|
}
|
|
|
|
return ret;
|
2005-08-04 09:15:49 +04:00
|
|
|
}
|