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.
2274 Commits
6 Branches
36 Tags
131 MiB
Tree: 69e0c25641
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '69e0c25641'
${ noResults }
git/rev-parse.c

303 lines
5.8 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"
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.
20 years ago
#include "refs.h"
[PATCH] Teach "git-rev-parse" about date-based cut-offs This adds the options "--since=date" and "--before=date" to git-rev-parse, which knows how to translate them into seconds since the epoch for git-rev-list. With this, you can do git log --since="2 weeks ago" or git log --until=yesterday to show the commits that have happened in the last two weeks or are older than 24 hours, respectively. The flags "--after=" and "--before" are synonyms for --since and --until, and you can combine them, so git log --after="Aug 5" --before="Aug 10" is a valid (but strange) thing to do. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
#include "quote.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
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
#define DO_REVS 1
#define DO_NOREV 2
#define DO_FLAGS 4
#define DO_NONFLAGS 8
static int filter = ~0;
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).
20 years ago
static char *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.
20 years ago
#define NORMAL 0
#define REVERSED 1
static int show_type = NORMAL;
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
static int symbolic = 0;
static int output_sq = 0;
static int revs_count = 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.
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[] = {
upload-pack: Do not choke on too many heads request. Cloning from a repository with more than 256 refs (heads and tags included) will choke, because upload-pack has a built-in limit of feeding not more than MAX_NEEDS (currently 256) heads to underlying git-rev-list. This is a problem when cloning a repository with many tags, like http://www.linux-mips.org/pub/scm/linux.git, which has 290+ tags. This commit introduces a new flag, --all, to git-rev-list, to include all refs in the repository. Updated upload-pack detects requests that ask more than MAX_NEEDS refs, and sends everything back instead. We may probably want to tweak the definitions of MAX_NEEDS and MAX_HAS, but that is a separate topic. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
"--all",
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
"--bisect",
"--header",
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
20 years ago
"--max-age=",
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
"--max-count=",
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
20 years ago
"--merge-order",
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
"--min-age=",
Update rev-parse flags list. I haven't audited the rev-parse users, but I am having a feeling that many of them would choke when they expect a couple of SHA1 object names and malicious user feeds them "--max-count=6" or somesuch to shoot himself in the foot. Anyway, this adds a couple of missing parameters that affect the list of revs to be returned from rev-list, not the flags that affect how they are presented by rev-list. I think that is the intention, but I am not quite sure. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
"--no-merges",
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
"--objects",
"--parents",
"--pretty",
"--show-breaks",
"--topo-order",
"--unpacked",
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
20 years ago
NULL
};
const char **p = rev_args;
for (;;) {
const char *str = *p++;
int len;
if (!str)
return 0;
len = strlen(str);
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
if (!strcmp(arg, str) ||
(str[len-1] == '=' && !strncmp(arg, str, len)))
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
20 years ago
return 1;
}
}
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
/* Output argument as a string, either SQ or normal */
[PATCH] Help scripts that use git-rev-parse to grok args with SP/TAB/LF The git-rev-parse command uses LF to separate each argument it parses, so its users at least need to set IFS to LF to be able to handle filenames with embedded SPs and TABs. Some commands, however, can take and do expect arguments with embedded LF, notably, "-S" (pickaxe) of diff family, so even this workaround does not work for them. When --sq flag to git-rev-parse is given, instead of showing one argument per line, it outputs arguments quoted for consumption with "eval" by the caller, to remedy this situation. As an example, this patch converts git-whatchanged to use this new feature. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
20 years ago
static void show(const char *arg)
{
if (output_sq) {
int sq = '\'', ch;
putchar(sq);
while ((ch = *arg++)) {
if (ch == sq)
fputs("'\\'", stdout);
putchar(ch);
}
putchar(sq);
putchar(' ');
}
else
puts(arg);
}
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
/* Output a revision, only if filter allows it */
Add --symbolic flag to git-rev-parse. This is most useful with --all, --revs-only, --no-flags and --verify. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
static void show_rev(int type, const unsigned char *sha1, const char *name)
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).
20 years ago
{
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
if (!(filter & DO_REVS))
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).
20 years ago
return;
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
def = NULL;
revs_count++;
[PATCH] Help scripts that use git-rev-parse to grok args with SP/TAB/LF The git-rev-parse command uses LF to separate each argument it parses, so its users at least need to set IFS to LF to be able to handle filenames with embedded SPs and TABs. Some commands, however, can take and do expect arguments with embedded LF, notably, "-S" (pickaxe) of diff family, so even this workaround does not work for them. When --sq flag to git-rev-parse is given, instead of showing one argument per line, it outputs arguments quoted for consumption with "eval" by the caller, to remedy this situation. As an example, this patch converts git-whatchanged to use this new feature. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
20 years ago
Add --symbolic flag to git-rev-parse. This is most useful with --all, --revs-only, --no-flags and --verify. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
if (type != show_type)
putchar('^');
if (symbolic && name)
show(name);
else
show(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).
20 years ago
}
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
/* Output a flag, only if filter allows it. */
static void show_flag(char *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).
20 years ago
{
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
if (!(filter & DO_FLAGS))
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).
20 years ago
return;
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
if (filter & (is_rev_argument(arg) ? DO_REVS : DO_NOREV))
[PATCH] Fix git-rev-parse --default and --flags handling This makes the argument to --default and any --flags arguments should up correctly, and makes "--" together with --flags act sanely. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
show(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).
20 years ago
}
static void show_default(void)
{
char *s = def;
if (s) {
unsigned char sha1[20];
def = NULL;
Update get_sha1() to grok extended format. Everybody envies rev-parse, who is the only one that can grok the extended sha1 format. Move the get_extended_sha1() out of rev-parse, rename it to get_sha1() and make it available to everybody else. The one I posted earlier to the list had one bug where it did not handle a name that ends with a digit correctly (it incorrectly tried the "Nth parent" path). This commit fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
if (!get_sha1(s, sha1)) {
Add --symbolic flag to git-rev-parse. This is most useful with --all, --revs-only, --no-flags and --verify. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
show_rev(NORMAL, sha1, s);
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).
20 years ago
return;
}
}
}
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.
20 years ago
static int show_reference(const char *refname, const unsigned char *sha1)
{
Add --symbolic flag to git-rev-parse. This is most useful with --all, --revs-only, --no-flags and --verify. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
show_rev(NORMAL, sha1, refname);
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.
20 years ago
return 0;
}
[PATCH] Teach "git-rev-parse" about date-based cut-offs This adds the options "--since=date" and "--before=date" to git-rev-parse, which knows how to translate them into seconds since the epoch for git-rev-list. With this, you can do git log --since="2 weeks ago" or git log --until=yesterday to show the commits that have happened in the last two weeks or are older than 24 hours, respectively. The flags "--after=" and "--before" are synonyms for --since and --until, and you can combine them, so git log --after="Aug 5" --before="Aug 10" is a valid (but strange) thing to do. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
static void show_datestring(const char *flag, const char *datestr)
{
FILE *date;
static char buffer[100];
static char cmd[1000];
int len;
/* date handling requires both flags and revs */
if ((filter & (DO_FLAGS | DO_REVS)) != (DO_FLAGS | DO_REVS))
return;
len = strlen(flag);
memcpy(buffer, flag, len);
snprintf(cmd, sizeof(cmd), "date --date=%s +%%s", sq_quote(datestr));
date = popen(cmd, "r");
if (!date || !fgets(buffer + len, sizeof(buffer) - len, date))
die("git-rev-list: bad date string");
pclose(date);
len = strlen(buffer);
if (buffer[len-1] == '\n')
buffer[--len] = 0;
show(buffer);
}
Avoid ambiguity between refname and filename in rev-parse Although it really is very convenient, not requiring explicit '-r' option to name revs is sometimes ambiguous. Usually we allow a "--" to say where a filename starts when it _is_ ambiguous. However, we fail that at times. In particular, git-rev-parse fails it. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
static void show_file(const char *arg)
{
git-rev-list: make --dense the default (and introduce "--sparse") This actually does three things: - make "--dense" the default for git-rev-list. Since dense is a no-op if no filenames are given, this doesn't actually change any historical behaviour, but it's logically the right default (if we want to prune on filenames, do it fully. The sparse "merge-only" thing may be useful, but it's not what you'd normally expect) - make "git-rev-parse" show the default revision control before it shows any pathnames. This was a real bug, but nobody would ever have noticed, because the default thing tends to only make sense for git-rev-list, and git-rev-list didn't use to take pathnames. - it changes "git-rev-list" to match the other commands that take a mix of revisions and filenames - it no longer requires the "--" before filenames (although you still need to do it if a filename could be confused with a revision name, eg "gitk" in the git archive) This all just makes for much more pleasant and obvous usage. Just doing a gitk t/ does the obvious thing: it will show the history as it concerns the "t/" subdirectory. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
show_default();
Avoid ambiguity between refname and filename in rev-parse Although it really is very convenient, not requiring explicit '-r' option to name revs is sometimes ambiguous. Usually we allow a "--" to say where a filename starts when it _is_ ambiguous. However, we fail that at times. In particular, git-rev-parse fails it. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
if ((filter & (DO_NONFLAGS|DO_NOREV)) == (DO_NONFLAGS|DO_NOREV))
show(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.
20 years ago
int main(int argc, char **argv)
{
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
int i, as_is = 0, verify = 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
unsigned char sha1[20];
[PATCH] Make "git diff" work inside relative subdirectories We always show the diff as an absolute path, but pathnames to diff are taken relative to the current working directory (and if no pathnames are given, the default ends up being all of the current working directory). Note that "../xyz" also works, so you can do cd linux/drivers/char git diff ../block and it will generate a diff of the linux/drivers/block changes. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
const char *prefix = setup_git_directory();
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
for (i = 1; i < argc; i++) {
char *arg = argv[i];
char *dotdot;
if (as_is) {
Avoid ambiguity between refname and filename in rev-parse Although it really is very convenient, not requiring explicit '-r' option to name revs is sometimes ambiguous. Usually we allow a "--" to say where a filename starts when it _is_ ambiguous. However, we fail that at times. In particular, git-rev-parse fails it. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
show_file(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.
20 years ago
continue;
}
if (*arg == '-') {
if (!strcmp(arg, "--")) {
as_is = 1;
git-rev-parse: pass on "--" flag when required If rev-parse output includes both flags and files, we should pass on any "--" marker we see, so that the end result can also tell the difference between a flag and a filename that begins with '-'. [jc: merged a later one liner updates from Linus] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
/* Pass on the "--" if we show anything but files.. */
if (filter & (DO_FLAGS | DO_REVS))
show_file(arg);
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
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
}
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.
20 years ago
if (!strcmp(arg, "--revs-only")) {
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
filter &= ~DO_NOREV;
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
continue;
}
if (!strcmp(arg, "--no-revs")) {
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
filter &= ~DO_REVS;
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
continue;
}
Add "--flags" and "--no-flags" arguments to git-rev-parse The scripts that use this (notably "git diff") will want to split up flags and file arguments.
20 years ago
if (!strcmp(arg, "--flags")) {
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
filter &= ~DO_NONFLAGS;
Add "--flags" and "--no-flags" arguments to git-rev-parse The scripts that use this (notably "git diff") will want to split up flags and file arguments.
20 years ago
continue;
}
if (!strcmp(arg, "--no-flags")) {
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
filter &= ~DO_FLAGS;
Add "--flags" and "--no-flags" arguments to git-rev-parse The scripts that use this (notably "git diff") will want to split up flags and file arguments.
20 years ago
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).
20 years ago
if (!strcmp(arg, "--verify")) {
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
filter &= ~(DO_FLAGS|DO_NOREV);
verify = 1;
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).
20 years ago
continue;
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
20 years ago
}
[PATCH] Help scripts that use git-rev-parse to grok args with SP/TAB/LF The git-rev-parse command uses LF to separate each argument it parses, so its users at least need to set IFS to LF to be able to handle filenames with embedded SPs and TABs. Some commands, however, can take and do expect arguments with embedded LF, notably, "-S" (pickaxe) of diff family, so even this workaround does not work for them. When --sq flag to git-rev-parse is given, instead of showing one argument per line, it outputs arguments quoted for consumption with "eval" by the caller, to remedy this situation. As an example, this patch converts git-whatchanged to use this new feature. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
20 years ago
if (!strcmp(arg, "--sq")) {
output_sq = 1;
continue;
}
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.
20 years ago
if (!strcmp(arg, "--not")) {
show_type ^= REVERSED;
continue;
}
Add --symbolic flag to git-rev-parse. This is most useful with --all, --revs-only, --no-flags and --verify. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
if (!strcmp(arg, "--symbolic")) {
symbolic = 1;
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.
20 years ago
if (!strcmp(arg, "--all")) {
for_each_ref(show_reference);
continue;
}
[PATCH] Make "git diff" work inside relative subdirectories We always show the diff as an absolute path, but pathnames to diff are taken relative to the current working directory (and if no pathnames are given, the default ends up being all of the current working directory). Note that "../xyz" also works, so you can do cd linux/drivers/char git diff ../block and it will generate a diff of the linux/drivers/block changes. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
if (!strcmp(arg, "--show-prefix")) {
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
if (prefix)
puts(prefix);
[PATCH] Make "git diff" work inside relative subdirectories We always show the diff as an absolute path, but pathnames to diff are taken relative to the current working directory (and if no pathnames are given, the default ends up being all of the current working directory). Note that "../xyz" also works, so you can do cd linux/drivers/char git diff ../block and it will generate a diff of the linux/drivers/block changes. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
continue;
}
[PATCH] Add "--git-dir" flag to git-rev-parse Especially when you're deep inside the git repository, it's not all that trivial for scripts to figure out where GIT_DIR is if it isn't set. So add a flag to git-rev-parse to show where it is, since it will have figured it out anyway. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
if (!strcmp(arg, "--git-dir")) {
const char *gitdir = getenv(GIT_DIR_ENVIRONMENT);
static char cwd[PATH_MAX];
if (gitdir) {
puts(gitdir);
continue;
}
if (!prefix) {
puts(".git");
continue;
}
if (!getcwd(cwd, PATH_MAX))
die("unable to get current working directory");
printf("%s/.git\n", cwd);
continue;
}
[PATCH] Teach "git-rev-parse" about date-based cut-offs This adds the options "--since=date" and "--before=date" to git-rev-parse, which knows how to translate them into seconds since the epoch for git-rev-list. With this, you can do git log --since="2 weeks ago" or git log --until=yesterday to show the commits that have happened in the last two weeks or are older than 24 hours, respectively. The flags "--after=" and "--before" are synonyms for --since and --until, and you can combine them, so git log --after="Aug 5" --before="Aug 10" is a valid (but strange) thing to do. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
if (!strncmp(arg, "--since=", 8)) {
show_datestring("--max-age=", arg+8);
continue;
}
if (!strncmp(arg, "--after=", 8)) {
show_datestring("--max-age=", arg+8);
continue;
}
if (!strncmp(arg, "--before=", 9)) {
show_datestring("--min-age=", arg+9);
continue;
}
if (!strncmp(arg, "--until=", 8)) {
show_datestring("--min-age=", arg+8);
continue;
}
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
if (verify)
die("Needed a single revision");
show_flag(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.
20 years ago
continue;
}
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
/* Not a flag argument */
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
dotdot = strstr(arg, "..");
if (dotdot) {
unsigned char end[20];
char *n = dotdot+2;
*dotdot = 0;
Update get_sha1() to grok extended format. Everybody envies rev-parse, who is the only one that can grok the extended sha1 format. Move the get_extended_sha1() out of rev-parse, rename it to get_sha1() and make it available to everybody else. The one I posted earlier to the list had one bug where it did not handle a name that ends with a digit correctly (it incorrectly tried the "Nth parent" path). This commit fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
if (!get_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";
Update get_sha1() to grok extended format. Everybody envies rev-parse, who is the only one that can grok the extended sha1 format. Move the get_extended_sha1() out of rev-parse, rename it to get_sha1() and make it available to everybody else. The one I posted earlier to the list had one bug where it did not handle a name that ends with a digit correctly (it incorrectly tried the "Nth parent" path). This commit fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
if (!get_sha1(n, end)) {
Add --symbolic flag to git-rev-parse. This is most useful with --all, --revs-only, --no-flags and --verify. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
show_rev(NORMAL, end, n);
show_rev(REVERSED, sha1, 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.
20 years ago
continue;
}
}
*dotdot = '.';
}
Update get_sha1() to grok extended format. Everybody envies rev-parse, who is the only one that can grok the extended sha1 format. Move the get_extended_sha1() out of rev-parse, rename it to get_sha1() and make it available to everybody else. The one I posted earlier to the list had one bug where it did not handle a name that ends with a digit correctly (it incorrectly tried the "Nth parent" path). This commit fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
if (!get_sha1(arg, sha1)) {
Add --symbolic flag to git-rev-parse. This is most useful with --all, --revs-only, --no-flags and --verify. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
show_rev(NORMAL, sha1, arg);
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
continue;
}
Update get_sha1() to grok extended format. Everybody envies rev-parse, who is the only one that can grok the extended sha1 format. Move the get_extended_sha1() out of rev-parse, rename it to get_sha1() and make it available to everybody else. The one I posted earlier to the list had one bug where it did not handle a name that ends with a digit correctly (it incorrectly tried the "Nth parent" path). This commit fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
if (*arg == '^' && !get_sha1(arg+1, sha1)) {
Add --symbolic flag to git-rev-parse. This is most useful with --all, --revs-only, --no-flags and --verify. Signed-off-by: Junio C Hamano <junkio@cox.net>
20 years ago
show_rev(REVERSED, sha1, arg+1);
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
continue;
}
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
if (verify)
die("Needed a single revision");
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>
19 years ago
as_is = 1;
Avoid ambiguity between refname and filename in rev-parse Although it really is very convenient, not requiring explicit '-r' option to name revs is sometimes ambiguous. Usually we allow a "--" to say where a filename starts when it _is_ ambiguous. However, we fail that at times. In particular, git-rev-parse fails it. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
show_file(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).
20 years ago
}
show_default();
Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
if (verify && revs_count != 1)
die("Needed a single revision");
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
return 0;
}