development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-07-05 00:58:49 +00:00
Code Issues Projects Releases Wiki Activity
f97672225b
git/rev-parse.c

179 lines
3.2 KiB
C
Raw Normal View History

Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 17:06:50 +00:00
/*
* rev-parse.c
*
* Copyright (C) Linus Torvalds, 2005
*/
#include "cache.h"
Make rev-parse understand "extended sha1" syntax You can say "HEAD.p" for the "parent of HEAD". It nests, so HEAD.p2.p means parent of second parent of HEAD (which obviously depends on HEAD being a merge).
2005-06-21 03:28:09 +00:00
#include "commit.h"
static int get_extended_sha1(char *name, unsigned char *sha1);
Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 17:06:50 +00:00
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
2005-06-13 18:14:20 +00:00
/*
* Some arguments are relevant "revision" arguments,
* others are about output format or other details.
* This sorts it all out.
*/
static int is_rev_argument(const char *arg)
{
static const char *rev_args[] = {
"--max-count=",
"--max-age=",
"--min-age=",
"--merge-order",
NULL
};
const char **p = rev_args;
for (;;) {
const char *str = *p++;
int len;
if (!str)
return 0;
len = strlen(str);
if (!strncmp(arg, str, len))
return 1;
}
}
Make rev-parse understand "extended sha1" syntax You can say "HEAD.p" for the "parent of HEAD". It nests, so HEAD.p2.p means parent of second parent of HEAD (which obviously depends on HEAD being a merge).
2005-06-21 03:28:09 +00:00
static int get_parent(char *name, unsigned char *result, int idx)
{
unsigned char sha1[20];
int ret = get_extended_sha1(name, 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;
p = commit->parents;
while (p) {
if (!--idx) {
memcpy(result, p->item->object.sha1, 20);
return 0;
}
p = p->next;
}
return -1;
}
/*
* This is like "get_sha1()", except it allows "sha1 expressions",
Change parent syntax to "xyz^" instead of "xyz.p" The ".pN" thing might be a common ending of a tag, and in contrast, ^ already is a special character for revisions so use that instead.
2005-06-21 04:06:47 +00:00
* notably "xyz^" for "parent of xyz"
Make rev-parse understand "extended sha1" syntax You can say "HEAD.p" for the "parent of HEAD". It nests, so HEAD.p2.p means parent of second parent of HEAD (which obviously depends on HEAD being a merge).
2005-06-21 03:28:09 +00:00
*/
static int get_extended_sha1(char *name, unsigned char *sha1)
{
int parent;
int len = strlen(name);
parent = 1;
Change parent syntax to "xyz^" instead of "xyz.p" The ".pN" thing might be a common ending of a tag, and in contrast, ^ already is a special character for revisions so use that instead.
2005-06-21 04:06:47 +00:00
if (len > 2 && name[len-1] >= '1' && name[len-1] <= '9') {
Make rev-parse understand "extended sha1" syntax You can say "HEAD.p" for the "parent of HEAD". It nests, so HEAD.p2.p means parent of second parent of HEAD (which obviously depends on HEAD being a merge).
2005-06-21 03:28:09 +00:00
parent = name[len-1] - '0';
len--;
}
Change parent syntax to "xyz^" instead of "xyz.p" The ".pN" thing might be a common ending of a tag, and in contrast, ^ already is a special character for revisions so use that instead.
2005-06-21 04:06:47 +00:00
if (len > 1 && name[len-1] == '^') {
Make rev-parse understand "extended sha1" syntax You can say "HEAD.p" for the "parent of HEAD". It nests, so HEAD.p2.p means parent of second parent of HEAD (which obviously depends on HEAD being a merge).
2005-06-21 03:28:09 +00:00
int ret;
Change parent syntax to "xyz^" instead of "xyz.p" The ".pN" thing might be a common ending of a tag, and in contrast, ^ already is a special character for revisions so use that instead.
2005-06-21 04:06:47 +00:00
name[len-1] = 0;
Make rev-parse understand "extended sha1" syntax You can say "HEAD.p" for the "parent of HEAD". It nests, so HEAD.p2.p means parent of second parent of HEAD (which obviously depends on HEAD being a merge).
2005-06-21 03:28:09 +00:00
ret = get_parent(name, sha1, parent);
Change parent syntax to "xyz^" instead of "xyz.p" The ".pN" thing might be a common ending of a tag, and in contrast, ^ already is a special character for revisions so use that instead.
2005-06-21 04:06:47 +00:00
name[len-1] = '^';
Make rev-parse understand "extended sha1" syntax You can say "HEAD.p" for the "parent of HEAD". It nests, so HEAD.p2.p means parent of second parent of HEAD (which obviously depends on HEAD being a merge).
2005-06-21 03:28:09 +00:00
if (!ret)
return 0;
}
return get_sha1(name, sha1);
}
Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 17:06:50 +00:00
int main(int argc, char **argv)
{
git-rev-parse: split "revs" and "non-revs" Sometimes we only want to output revisions, and sometimes we want to only see the stuff that wasn't revisions. Teach git-rev-parse to understand the "--revs-only" and "--no-revs" flags.
2005-06-13 17:21:11 +00:00
int i, as_is = 0, revs_only = 0, no_revs = 0;
Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 17:06:50 +00:00
char *def = NULL;
unsigned char sha1[20];
for (i = 1; i < argc; i++) {
char *arg = argv[i];
char *dotdot;
if (as_is) {
printf("%s\n", arg);
continue;
}
if (*arg == '-') {
if (!strcmp(arg, "--")) {
if (def) {
printf("%s\n", def);
def = NULL;
}
git-rev-parse: split "revs" and "non-revs" Sometimes we only want to output revisions, and sometimes we want to only see the stuff that wasn't revisions. Teach git-rev-parse to understand the "--revs-only" and "--no-revs" flags.
2005-06-13 17:21:11 +00:00
if (revs_only)
break;
Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 17:06:50 +00:00
as_is = 1;
}
if (!strcmp(arg, "--default")) {
if (def)
printf("%s\n", def);
def = argv[i+1];
i++;
continue;
}
git-rev-parse: split "revs" and "non-revs" Sometimes we only want to output revisions, and sometimes we want to only see the stuff that wasn't revisions. Teach git-rev-parse to understand the "--revs-only" and "--no-revs" flags.
2005-06-13 17:21:11 +00:00
if (!strcmp(arg, "--revs-only")) {
revs_only = 1;
continue;
}
if (!strcmp(arg, "--no-revs")) {
no_revs = 1;
continue;
}
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
2005-06-13 18:14:20 +00:00
if (revs_only | no_revs) {
if (is_rev_argument(arg) != revs_only)
continue;
}
Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 17:06:50 +00:00
printf("%s\n", arg);
continue;
}
dotdot = strstr(arg, "..");
if (dotdot) {
unsigned char end[20];
char *n = dotdot+2;
*dotdot = 0;
Make rev-parse understand "extended sha1" syntax You can say "HEAD.p" for the "parent of HEAD". It nests, so HEAD.p2.p means parent of second parent of HEAD (which obviously depends on HEAD being a merge).
2005-06-21 03:28:09 +00:00
if (!get_extended_sha1(arg, sha1)) {
Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 17:06:50 +00:00
if (!*n)
n = "HEAD";
Make rev-parse understand "extended sha1" syntax You can say "HEAD.p" for the "parent of HEAD". It nests, so HEAD.p2.p means parent of second parent of HEAD (which obviously depends on HEAD being a merge).
2005-06-21 03:28:09 +00:00
if (!get_extended_sha1(n, end)) {
git-rev-parse: split "revs" and "non-revs" Sometimes we only want to output revisions, and sometimes we want to only see the stuff that wasn't revisions. Teach git-rev-parse to understand the "--revs-only" and "--no-revs" flags.
2005-06-13 17:21:11 +00:00
if (no_revs)
continue;
def = NULL;
Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 17:06:50 +00:00
printf("%s\n", sha1_to_hex(end));
printf("^%s\n", sha1_to_hex(sha1));
continue;
}
}
*dotdot = '.';
}
Make rev-parse understand "extended sha1" syntax You can say "HEAD.p" for the "parent of HEAD". It nests, so HEAD.p2.p means parent of second parent of HEAD (which obviously depends on HEAD being a merge).
2005-06-21 03:28:09 +00:00
if (!get_extended_sha1(arg, sha1)) {
git-rev-parse: parse ".." before simple SHA1's This fixes "<hexsha1>..*", since get_sha1() will happily ignore any garbage at the end and thus we never got to the ".." check before.
2005-06-20 15:29:13 +00:00
if (no_revs)
continue;
def = NULL;
printf("%s\n", sha1_to_hex(sha1));
continue;
}
Make rev-parse understand "extended sha1" syntax You can say "HEAD.p" for the "parent of HEAD". It nests, so HEAD.p2.p means parent of second parent of HEAD (which obviously depends on HEAD being a merge).
2005-06-21 03:28:09 +00:00
if (*arg == '^' && !get_extended_sha1(arg+1, sha1)) {
git-rev-parse: parse ".." before simple SHA1's This fixes "<hexsha1>..*", since get_sha1() will happily ignore any garbage at the end and thus we never got to the ".." check before.
2005-06-20 15:29:13 +00:00
if (no_revs)
continue;
def = NULL;
printf("^%s\n", sha1_to_hex(sha1));
continue;
}
git-rev-parse: flush "default" head when encountering something unexpected The unexpected thing is likely a pathname, we need the default for that too.
2005-06-20 23:14:13 +00:00
if (def) {
printf("%s\n", def);
def = NULL;
}
git-rev-parse: split "revs" and "non-revs" Sometimes we only want to output revisions, and sometimes we want to only see the stuff that wasn't revisions. Teach git-rev-parse to understand the "--revs-only" and "--no-revs" flags.
2005-06-13 17:21:11 +00:00
if (revs_only)
continue;
Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 17:06:50 +00:00
printf("%s\n", arg);
}
if (def)
printf("%s\n", def);
return 0;
}
Reference in New Issue Copy Permalink