kernel
/
git
mirror of https://git.kernel.org/pub/scm/git/git.git
1
0
Fork 0
Code Releases Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
776 Commits
6 Branches
36 Tags
131 MiB
Tree: a8be83fe00
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'a8be83fe00'
${ noResults }
git/rev-parse.c

179 lines
3.2 KiB
Raw Normal View History Unescape

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.
20 years ago
/*
* 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).
20 years ago
#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.
20 years ago
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
20 years ago
/*
* 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).
20 years ago
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",
* notably "xyz.p" for "parent of xyz"
*/
static int get_extended_sha1(char *name, unsigned char *sha1)
{
int parent;
int len = strlen(name);
parent = 1;
if (len > 3 && name[len-1] >= '1' && name[len-1] <= '9') {
parent = name[len-1] - '0';
len--;
}
if (len > 2 && !memcmp(name + len - 2, ".p", 2)) {
int ret;
name[len-2] = 0;
ret = get_parent(name, sha1, parent);
name[len-2] = '.';
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.
20 years ago
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.
20 years ago
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.
20 years ago
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.
20 years ago
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.
20 years ago
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.
20 years ago
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".
20 years ago
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.
20 years ago
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).
20 years ago
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.
20 years ago
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).
20 years ago
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.
20 years ago
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.
20 years ago
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).
20 years ago
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.
20 years ago
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).
20 years ago
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.
20 years ago
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.
20 years ago
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.
20 years ago
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.
20 years ago
printf("%s\n", arg);
}
if (def)
printf("%s\n", def);
return 0;
}