undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
b43d44779b
git-commit-vandalism/rev-parse.c

367 lines
6.7 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 19:06:50 +02: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 05:28:09 +02:00
#include "commit.h"
Add "--all" flag to rev-parse that shows all refs And make git-rev-list just silently ignore non-commit refs if we're not asking for all objects.
2005-07-03 22:07:52 +02:00
#include "refs.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 05:28:09 +02:00
git-rev-parse: re-organize and be more careful Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
2005-06-24 19:12:55 +02:00
static char *def = NULL;
static int no_revs = 0;
static int single_rev = 0;
static int revs_only = 0;
static int do_rev_argument = 1;
static int output_revs = 0;
git-rev-parse: add "--not" flag to mark subsequent heads negative If you have two lists of heads, and you want to see ones reachable from list $a but not from list $b, just do git-rev-list $(git-rev-parse $a --not $b) which is useful for both bisecting (where "b" would be the list of known good revisions, and "a" would be the latest found bad head) and for just seeing what the difference between two sets of heads are if you want to generate a pack-file for the difference.
2005-06-26 20:34:30 +02:00
#define NORMAL 0
#define REVERSED 1
static int show_type = NORMAL;
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 05:28:09 +02:00
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 19:06:50 +02:00
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
2005-06-13 20:14:20 +02: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;
}
}
Add "--all" flag to rev-parse that shows all refs And make git-rev-list just silently ignore non-commit refs if we're not asking for all objects.
2005-07-03 22:07:52 +02:00
static void show_rev(int type, const unsigned char *sha1)
git-rev-parse: re-organize and be more careful Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
2005-06-24 19:12:55 +02:00
{
if (no_revs)
return;
output_revs++;
git-rev-parse: add "--not" flag to mark subsequent heads negative If you have two lists of heads, and you want to see ones reachable from list $a but not from list $b, just do git-rev-list $(git-rev-parse $a --not $b) which is useful for both bisecting (where "b" would be the list of known good revisions, and "a" would be the latest found bad head) and for just seeing what the difference between two sets of heads are if you want to generate a pack-file for the difference.
2005-06-26 20:34:30 +02:00
printf("%s%s\n", type == show_type ? "" : "^", sha1_to_hex(sha1));
git-rev-parse: re-organize and be more careful Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
2005-06-24 19:12:55 +02:00
}
static void show_rev_arg(char *rev)
{
if (no_revs)
return;
puts(rev);
}
static void show_norev(char *norev)
{
if (revs_only)
return;
puts(norev);
}
static void show_arg(char *arg)
{
if (do_rev_argument && is_rev_argument(arg))
show_rev_arg(arg);
else
show_norev(arg);
}
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 05:28:09 +02: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;
}
Make git-rev-parse support cogito-style "short hex names" Currently only for unpacked objects, but the infrastructure is there to do it for packed objects too.
2005-07-04 05:27:06 +02:00
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
static char dirname[PATH_MAX];
char hex[40];
DIR *dir;
int found;
snprintf(dirname, sizeof(dirname), "%s/%.2s", get_object_directory(), name);
dir = opendir(dirname);
sprintf(hex, "%.2s", name);
found = 0;
if (dir) {
struct dirent *de;
while ((de = readdir(dir)) != NULL) {
if (strlen(de->d_name) != 38)
continue;
if (memcmp(de->d_name, name + 2, len-2))
continue;
memcpy(hex + 2, de->d_name, 38);
if (++found > 1)
break;
}
closedir(dir);
}
if (found == 1)
return get_sha1_hex(hex, sha1) == 0;
return 0;
}
git-rev-parse: support show sha1 names for pack entries This is actually subtly wrong. If a short match is found in the object directory, but would _also_ match another SHA1 ID in a pack (or it shows in one pack but not another), we'll never have done the pack lookup, and we think it's unique. I can't find it in myself to care. You really want to use enough of a SHA1 that there is never any ambiguity.
2005-07-04 06:01:11 +02: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;
}
Make git-rev-parse support cogito-style "short hex names" Currently only for unpacked objects, but the infrastructure is there to do it for packed objects too.
2005-07-04 05:27:06 +02:00
static int find_short_packed_object(int len, const unsigned char *match, unsigned char *sha1)
{
git-rev-parse: support show sha1 names for pack entries This is actually subtly wrong. If a short match is found in the object directory, but would _also_ match another SHA1 ID in a pack (or it shows in one pack but not another), we'll never have done the pack lookup, and we think it's unique. I can't find it in myself to care. You really want to use enough of a SHA1 that there is never any ambiguity.
2005-07-04 06:01:11 +02:00
struct packed_git *p;
prepare_packed_git();
for (p = packed_git; p; p = p->next) {
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) {
unsigned char now[20], next[20];
nth_packed_object_sha1(p, first, now);
if (match_sha(len, match, now)) {
if (nth_packed_object_sha1(p, first+1, next) || !match_sha(len, match, next)) {
memcpy(sha1, now, 20);
return 1;
}
}
}
}
Make git-rev-parse support cogito-style "short hex names" Currently only for unpacked objects, but the infrastructure is there to do it for packed objects too.
2005-07-04 05:27:06 +02:00
return 0;
}
static int get_short_sha1(char *name, unsigned char *sha1)
{
int i;
char canonical[40];
unsigned char res[20];
memset(res, 0, 20);
memset(canonical, 'x', 40);
for (i = 0;;i++) {
unsigned char c = name[i];
unsigned char val;
if (!c || i > 40)
break;
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;
}
if (i < 4)
return -1;
if (find_short_object_filename(i, canonical, sha1))
return 0;
if (find_short_packed_object(i, res, sha1))
return 0;
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 05:28:09 +02:00
/*
* 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 06:06:47 +02: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 05:28:09 +02:00
*/
static int get_extended_sha1(char *name, unsigned char *sha1)
{
Make git-rev-parse support cogito-style "short hex names" Currently only for unpacked objects, but the infrastructure is there to do it for packed objects too.
2005-07-04 05:27:06 +02:00
int parent, ret;
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 05:28:09 +02:00
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 06:06:47 +02: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 05:28:09 +02: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 06:06:47 +02:00
if (len > 1 && name[len-1] == '^') {
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 05:28:09 +02: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 06:06:47 +02: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 05:28:09 +02:00
if (!ret)
return 0;
}
Make git-rev-parse support cogito-style "short hex names" Currently only for unpacked objects, but the infrastructure is there to do it for packed objects too.
2005-07-04 05:27:06 +02:00
ret = get_sha1(name, sha1);
if (!ret)
return 0;
return get_short_sha1(name, sha1);
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 05:28:09 +02:00
}
git-rev-parse: re-organize and be more careful Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
2005-06-24 19:12:55 +02:00
static void show_default(void)
{
char *s = def;
if (s) {
unsigned char sha1[20];
def = NULL;
if (!get_extended_sha1(s, sha1)) {
git-rev-parse: add "--not" flag to mark subsequent heads negative If you have two lists of heads, and you want to see ones reachable from list $a but not from list $b, just do git-rev-list $(git-rev-parse $a --not $b) which is useful for both bisecting (where "b" would be the list of known good revisions, and "a" would be the latest found bad head) and for just seeing what the difference between two sets of heads are if you want to generate a pack-file for the difference.
2005-06-26 20:34:30 +02:00
show_rev(NORMAL, sha1);
git-rev-parse: re-organize and be more careful Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
2005-06-24 19:12:55 +02:00
return;
}
show_arg(s);
}
}
Add "--all" flag to rev-parse that shows all refs And make git-rev-list just silently ignore non-commit refs if we're not asking for all objects.
2005-07-03 22:07:52 +02:00
static int show_reference(const char *refname, const unsigned char *sha1)
{
show_rev(NORMAL, sha1);
return 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 19:06:50 +02:00
int main(int argc, char **argv)
{
git-rev-parse: re-organize and be more careful Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
2005-06-24 19:12:55 +02:00
int i, as_is = 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 19:06:50 +02:00
unsigned char sha1[20];
for (i = 1; i < argc; i++) {
char *arg = argv[i];
char *dotdot;
if (as_is) {
git-rev-parse: re-organize and be more careful Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
2005-06-24 19:12:55 +02:00
show_norev(arg);
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 19:06:50 +02:00
continue;
}
if (*arg == '-') {
if (!strcmp(arg, "--")) {
git-rev-parse: re-organize and be more careful Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
2005-06-24 19:12:55 +02:00
show_default();
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 19:21:11 +02: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 19:06:50 +02:00
as_is = 1;
}
if (!strcmp(arg, "--default")) {
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 19:21:11 +02:00
if (!strcmp(arg, "--revs-only")) {
revs_only = 1;
continue;
}
if (!strcmp(arg, "--no-revs")) {
no_revs = 1;
continue;
}
git-rev-parse: re-organize and be more careful Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
2005-06-24 19:12:55 +02:00
if (!strcmp(arg, "--verify")) {
revs_only = 1;
do_rev_argument = 0;
single_rev = 1;
continue;
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
2005-06-13 20:14:20 +02:00
}
git-rev-parse: add "--not" flag to mark subsequent heads negative If you have two lists of heads, and you want to see ones reachable from list $a but not from list $b, just do git-rev-list $(git-rev-parse $a --not $b) which is useful for both bisecting (where "b" would be the list of known good revisions, and "a" would be the latest found bad head) and for just seeing what the difference between two sets of heads are if you want to generate a pack-file for the difference.
2005-06-26 20:34:30 +02:00
if (!strcmp(arg, "--not")) {
show_type ^= REVERSED;
continue;
}
Add "--all" flag to rev-parse that shows all refs And make git-rev-list just silently ignore non-commit refs if we're not asking for all objects.
2005-07-03 22:07:52 +02:00
if (!strcmp(arg, "--all")) {
for_each_ref(show_reference);
continue;
}
git-rev-parse: re-organize and be more careful Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
2005-06-24 19:12:55 +02:00
show_arg(arg);
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 19:06:50 +02:00
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 05:28:09 +02: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 19:06:50 +02: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 05:28:09 +02: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 19:21:11 +02:00
if (no_revs)
continue;
def = NULL;
git-rev-parse: add "--not" flag to mark subsequent heads negative If you have two lists of heads, and you want to see ones reachable from list $a but not from list $b, just do git-rev-list $(git-rev-parse $a --not $b) which is useful for both bisecting (where "b" would be the list of known good revisions, and "a" would be the latest found bad head) and for just seeing what the difference between two sets of heads are if you want to generate a pack-file for the difference.
2005-06-26 20:34:30 +02:00
show_rev(NORMAL, end);
show_rev(REVERSED, 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 19:06:50 +02:00
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 05:28:09 +02: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 17:29:13 +02:00
if (no_revs)
continue;
def = NULL;
git-rev-parse: add "--not" flag to mark subsequent heads negative If you have two lists of heads, and you want to see ones reachable from list $a but not from list $b, just do git-rev-list $(git-rev-parse $a --not $b) which is useful for both bisecting (where "b" would be the list of known good revisions, and "a" would be the latest found bad head) and for just seeing what the difference between two sets of heads are if you want to generate a pack-file for the difference.
2005-06-26 20:34:30 +02:00
show_rev(NORMAL, 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 17:29:13 +02:00
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 05:28:09 +02: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 17:29:13 +02:00
if (no_revs)
continue;
def = NULL;
git-rev-parse: add "--not" flag to mark subsequent heads negative If you have two lists of heads, and you want to see ones reachable from list $a but not from list $b, just do git-rev-list $(git-rev-parse $a --not $b) which is useful for both bisecting (where "b" would be the list of known good revisions, and "a" would be the latest found bad head) and for just seeing what the difference between two sets of heads are if you want to generate a pack-file for the difference.
2005-06-26 20:34:30 +02:00
show_rev(REVERSED, 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 17:29:13 +02:00
continue;
}
git-rev-parse: re-organize and be more careful Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
2005-06-24 19:12:55 +02:00
show_default();
show_norev(arg);
}
show_default();
if (single_rev && output_revs != 1) {
fprintf(stderr, "Needed a single revision\n");
exit(1);
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 19:06:50 +02:00
}
return 0;
}
Reference in New Issue Copy Permalink