microsoft
/
git
зеркало из https://github.com/microsoft/git.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
git/rev-parse.c

365 строки
7.1 KiB
C
Исходник Обычный вид История

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 21:06:50 +04: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 07:28:09 +04: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-04 00:07:52 +04:00
#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>
2005-09-21 01:13:24 +04:00
#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).
2005-06-21 07:28:09 +04:00
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>
2005-08-25 01:30:04 +04:00
#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).
2005-06-24 21:12:55 +04:00
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.
2005-06-26 22:34:30 +04:00
#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>
2005-08-25 01:30:04 +04:00
static int symbolic = 0;
rev-parse: --abbrev option. The new option behaves just like --verify, but outputs an abbreviated object name that is unique within the repository. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-25 12:35:38 +03:00
static int abbrev = 0;
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>
2005-08-25 01:30:04 +04:00
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.
2005-06-26 22:34:30 +04:00
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
2005-06-13 22:14:20 +04: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[] = {
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>
2005-10-06 01:49:54 +04:00
"--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>
2005-08-25 01:30:04 +04:00
"--bisect",
Update git-rev-list options list in rev-parse. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-30 12:08:35 +03:00
"--dense",
Add "--branches", "--tags" and "--remotes" options to git-rev-parse. "git branch" uses "rev-parse --all" and becomes much too slow when there are many tags (it scans all refs). Use the new "--branches" option of rev-parse to speed things up. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-14 05:43:00 +04:00
"--branches",
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>
2005-08-25 01:30:04 +04:00
"--header",
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
2005-06-13 22:14:20 +04:00
"--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>
2005-08-25 01:30:04 +04:00
"--max-count=",
"--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>
2005-08-09 06:31:37 +04:00
"--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>
2005-08-25 01:30:04 +04:00
"--objects",
rev-list --objects-edge This new flag is similar to --objects, but causes rev-list to show list of "uninteresting" commits that appear on the edge commit prefixed with '-'. Downstream pack-objects will be changed to take these as hints to use the trees and blobs contained with them as base objects of resulting pack, producing an incomplete (not self-contained) pack. Such a pack cannot be used in .git/objects/pack (it is prevented by git-index-pack erroring out if it is fed to git-fetch-pack -k or git-clone-pack), but would be useful when transferring only small changes to huge blobs. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-19 14:32:31 +03:00
"--objects-edge",
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>
2005-08-25 01:30:04 +04:00
"--parents",
"--pretty",
Add "--branches", "--tags" and "--remotes" options to git-rev-parse. "git branch" uses "rev-parse --all" and becomes much too slow when there are many tags (it scans all refs). Use the new "--branches" option of rev-parse to speed things up. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-14 05:43:00 +04:00
"--remotes",
Update git-rev-list options list in rev-parse. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-30 12:08:35 +03:00
"--sparse",
Add "--branches", "--tags" and "--remotes" options to git-rev-parse. "git branch" uses "rev-parse --all" and becomes much too slow when there are many tags (it scans all refs). Use the new "--branches" option of rev-parse to speed things up. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-14 05:43:00 +04:00
"--tags",
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>
2005-08-25 01:30:04 +04:00
"--topo-order",
topo-order: make --date-order optional. This adds --date-order to rev-list; it is similar to topo order in the sense that no parent comes before all of its children, but otherwise things are still ordered in the commit timestamp order. The same flag is also added to show-branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-16 09:05:33 +03:00
"--date-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>
2005-08-25 01:30:04 +04:00
"--unpacked",
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
2005-06-13 22:14:20 +04:00
NULL
};
const char **p = rev_args;
rev-list: allow -<n> as shorthand for --max-count=<n> This builds on top of the previous one. Traditionally, head(1) and tail(1) allow their line limits to be parsed this way. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-30 03:28:02 +03:00
/* accept -<digit>, like traditional "head" */
if ((*arg == '-') && isdigit(arg[1]))
return 1;
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
2005-06-13 22:14:20 +04:00
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>
2005-08-25 01:30:04 +04:00
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".
2005-06-13 22:14:20 +04:00
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>
2005-08-25 01:30:04 +04:00
/* 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>
2005-07-23 06:08:32 +04:00
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>
2005-08-25 01:30:04 +04:00
/* 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>
2005-08-16 23:36:46 +04:00
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).
2005-06-24 21:12:55 +04:00
{
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>
2005-08-25 01:30:04 +04:00
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).
2005-06-24 21:12:55 +04:00
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>
2005-08-25 01:30:04 +04:00
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>
2005-07-23 06:08:32 +04:00
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>
2005-08-16 23:36:46 +04:00
if (type != show_type)
putchar('^');
if (symbolic && name)
show(name);
rev-parse: --abbrev option. The new option behaves just like --verify, but outputs an abbreviated object name that is unique within the repository. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-25 12:35:38 +03:00
else if (abbrev)
show(find_unique_abbrev(sha1, abbrev));
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>
2005-08-16 23:36:46 +04:00
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).
2005-06-24 21:12:55 +04:00
}
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>
2005-08-25 01:30:04 +04:00
/* Output a flag, only if filter allows it. */
Fix git-rev-parse over-eager errors Using "--verify" together with "--no-flags" makes perfect sense, but git-rev-parse would complain about it when it saw a flag, even though it would never actually use/output that flag. This fixes it. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 22:58:34 +03:00
static int 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).
2005-06-24 21:12:55 +04:00
{
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>
2005-08-25 01:30:04 +04:00
if (!(filter & DO_FLAGS))
Fix git-rev-parse over-eager errors Using "--verify" together with "--no-flags" makes perfect sense, but git-rev-parse would complain about it when it saw a flag, even though it would never actually use/output that flag. This fixes it. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 22:58:34 +03:00
return 0;
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>
2005-08-23 21:47:54 +04:00
show(arg);
Fix git-rev-parse over-eager errors Using "--verify" together with "--no-flags" makes perfect sense, but git-rev-parse would complain about it when it saw a flag, even though it would never actually use/output that flag. This fixes it. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 22:58:34 +03:00
return 1;
}
return 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).
2005-06-24 21:12:55 +04:00
}
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>
2005-08-04 09:15:49 +04:00
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>
2005-08-16 23:36:46 +04:00
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).
2005-06-24 21:12:55 +04:00
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.
2005-07-04 00:07:52 +04:00
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>
2005-08-16 23:36:46 +04:00
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.
2005-07-04 00:07:52 +04:00
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>
2005-09-21 01:13:24 +04:00
static void show_datestring(const char *flag, const char *datestr)
{
static char buffer[100];
/* date handling requires both flags and revs */
if ((filter & (DO_FLAGS | DO_REVS)) != (DO_FLAGS | DO_REVS))
return;
git's rev-parse.c function show_datestring presumes gnu date Ok. This is the insane patch to do this. It really isn't very careful, and the reason I call it "approxidate()" will become obvious when you look at the code. It is very liberal in what it accepts, to the point where sometimes the results may not make a whole lot of sense. It accepts "last week" as a date string, by virtue of "last" parsing as the number 1, and it totally ignoring superfluous fluff like "ago", so "last week" ends up being exactly the same thing as "1 week ago". Fine so far. It has strange side effects: "last december" will actually parse as "Dec 1", which actually _does_ turn out right, because it will then notice that it's not December yet, so it will decide that you must be talking about a date last year. So it actually gets it right, but it's kind of for the "wrong" reasons. It also accepts the numbers 1..10 in string format ("one" .. "ten"), so you can do "ten weeks ago" or "ten hours ago" and it will do the right thing. But it will do some really strange thigns too: the string "this will last forever", will not recognize anyting but "last", which is recognized as "1", which since it doesn't understand anything else it will think is the day of the month. So if you do gitk --since="this will last forever" the date will actually parse as the first day of the current month. And it will parse the string "now" as "now", but only because it doesn't understand it at all, and it makes everything relative to "now". Similarly, it doesn't actually parse the "ago" or "from now", so "2 weeks ago" is exactly the same as "2 weeks from now". It's the current date minus 14 days. But hey, it's probably better (and certainly faster) than depending on GNU date. So now you can portably do things like gitk --since="two weeks and three days ago" git log --since="July 5" git-whatchanged --since="10 hours ago" git log --since="last october" and it will actually do exactly what you thought it would do (I think). It will count 17 days backwards, and it will do so even if you don't have GNU date installed. (I don't do "last monday" or similar yet, but I can extend it to that too if people want). It was kind of fun trying to write code that uses such totally relaxed "understanding" of dates yet tries to get it right for the trivial cases. The result should be mixed with a few strange preprocessor tricks, and be submitted for the IOCCC ;) Feel free to try it out, and see how many strange dates it gets right. Or wrong. And if you find some interesting (and valid - not "interesting" as in "strange", but "interesting" as in "I'd be interested in actually doing this) thing it gets wrong - usually by not understanding it and silently just doing some strange things - please holler. Now, as usual this certainly hasn't been getting a lot of testing. But my code always works, no? Linus Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-15 06:29:06 +03:00
snprintf(buffer, sizeof(buffer), "%s%lu", flag, approxidate(datestr));
[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>
2005-09-21 01:13:24 +04:00
show(buffer);
}
rev-parse lstat() workaround cleanup. Earlier we had a workaround to avoid misspelled revision name to be taken as a filename when "--no-revs --no-flags" are in effect. This cleans up the logic. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 08:41:47 +03:00
static int show_file(const char *arg)
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>
2005-10-18 11:16:45 +04:00
{
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>
2005-10-26 02:24:55 +04:00
show_default();
rev-parse lstat() workaround cleanup. Earlier we had a workaround to avoid misspelled revision name to be taken as a filename when "--no-revs --no-flags" are in effect. This cleans up the logic. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 08:41:47 +03:00
if ((filter & (DO_NONFLAGS|DO_NOREV)) == (DO_NONFLAGS|DO_NOREV)) {
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>
2005-10-18 11:16:45 +04:00
show(arg);
rev-parse lstat() workaround cleanup. Earlier we had a workaround to avoid misspelled revision name to be taken as a filename when "--no-revs --no-flags" are in effect. This cleans up the logic. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 08:41:47 +03:00
return 1;
}
return 0;
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>
2005-10-18 11:16:45 +04:00
}
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 21:06:50 +04:00
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>
2005-08-25 01:30:04 +04:00
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.
2005-06-13 21:06:50 +04:00
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>
2005-08-17 05:06:34 +04:00
const char *prefix = setup_git_directory();
Add "--branches", "--tags" and "--remotes" options to git-rev-parse. "git branch" uses "rev-parse --all" and becomes much too slow when there are many tags (it scans all refs). Use the new "--branches" option of rev-parse to speed things up. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-14 05:43:00 +04:00
sha1_name: warning ambiguous refs. This makes sure that many commands that take refs on the command line to honor core.warnambiguousrefs configuration. Earlier, the commands affected by this patch did not read the configuration file. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-24 10:41:18 +03:00
git_config(git_default_config);
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 21:06:50 +04:00
for (i = 1; i < argc; i++) {
char *arg = argv[i];
char *dotdot;
Fix error handling for nonexistent names When passing in a pathname pattern without the "--" separator on the command line, we verify that the pathnames in question exist. However, there were two bugs in that verification: - git-rev-parse would only check the first pathname, and silently allow any invalid subsequent pathname, whether it existed or not (which defeats the purpose of the check, and is also inconsistent with what git-rev-list actually does) - git-rev-list (and "git log" etc) would check each filename, but if the check failed, it would print the error using the first one, i.e.: [torvalds@g5 git]$ git log Makefile bad-file fatal: 'Makefile': No such file or directory instead of saying that it's 'bad-file' that doesn't exist. This fixes both bugs. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-27 04:28:20 +04:00
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 21:06:50 +04:00
if (as_is) {
Fix error handling for nonexistent names When passing in a pathname pattern without the "--" separator on the command line, we verify that the pathnames in question exist. However, there were two bugs in that verification: - git-rev-parse would only check the first pathname, and silently allow any invalid subsequent pathname, whether it existed or not (which defeats the purpose of the check, and is also inconsistent with what git-rev-list actually does) - git-rev-list (and "git log" etc) would check each filename, but if the check failed, it would print the error using the first one, i.e.: [torvalds@g5 git]$ git log Makefile bad-file fatal: 'Makefile': No such file or directory instead of saying that it's 'bad-file' that doesn't exist. This fixes both bugs. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-27 04:28:20 +04:00
if (show_file(arg) && as_is < 2)
Fix filename verification when in a subdirectory When we are in a subdirectory of a git archive, we need to take the prefix of that subdirectory into accoung when we verify filename arguments. Noted by Matthias Lederhofer This also uses the improved error reporting for all the other git commands that use the revision parsing interfaces, not just git-rev-parse. Also, it makes the error reporting for mixed filenames and argument flags clearer (you cannot put flags after the start of the pathname list). [jc: with fix to a trivial typo noticed by Timo Hirvonen] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-26 21:15:54 +04:00
verify_filename(prefix, 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 21:06:50 +04:00
continue;
}
rev-list: allow -n<n> as shorthand for --max-count=<n> Both -n<n> and -n <n> are supported. POSIX versions of head(1) and tail(1) allow their line limits to be parsed this way. I find --max-count to be a commonly used option, and also similar in spirit to head/tail, so I decided to make life easier on my worn out (and lazy :) fingers with this patch. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-30 03:26:40 +03:00
if (!strcmp(arg,"-n")) {
if (++i >= argc)
die("-n requires an argument");
if ((filter & DO_FLAGS) && (filter & DO_REVS)) {
show(arg);
show(argv[i]);
}
continue;
}
if (!strncmp(arg,"-n",2)) {
if ((filter & DO_FLAGS) && (filter & DO_REVS))
show(arg);
continue;
}
Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 21:06:50 +04:00
if (*arg == '-') {
if (!strcmp(arg, "--")) {
Fix error handling for nonexistent names When passing in a pathname pattern without the "--" separator on the command line, we verify that the pathnames in question exist. However, there were two bugs in that verification: - git-rev-parse would only check the first pathname, and silently allow any invalid subsequent pathname, whether it existed or not (which defeats the purpose of the check, and is also inconsistent with what git-rev-list actually does) - git-rev-list (and "git log" etc) would check each filename, but if the check failed, it would print the error using the first one, i.e.: [torvalds@g5 git]$ git log Makefile bad-file fatal: 'Makefile': No such file or directory instead of saying that it's 'bad-file' that doesn't exist. This fixes both bugs. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-27 04:28:20 +04:00
as_is = 2;
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>
2005-10-21 04:16:30 +04:00
/* 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>
2005-08-25 01:30:04 +04:00
continue;
Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 21:06:50 +04:00
}
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 21:21:11 +04:00
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>
2005-08-25 01:30:04 +04:00
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.
2005-06-13 21:21:11 +04:00
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>
2005-08-25 01:30:04 +04:00
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.
2005-06-13 21:21:11 +04:00
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.
2005-07-06 21:08:08 +04:00
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>
2005-08-25 01:30:04 +04:00
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.
2005-07-06 21:08:08 +04:00
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>
2005-08-25 01:30:04 +04:00
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.
2005-07-06 21:08:08 +04: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 21:12:55 +04:00
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>
2005-08-25 01:30:04 +04:00
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).
2005-06-24 21:12:55 +04:00
continue;
Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".
2005-06-13 22:14:20 +04:00
}
Rename rev-parse --abbrev to --short. The usage of rev-parse to serve as a flag/option parser for git-whatchanged and other commands have serious limitation that the flags cannot be something that is supported by rev-parse itself, and it cannot worked around easily. Since this is rarely used "poor-man's describe", rename the option for now as an easier workaround. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-27 04:02:07 +03:00
if (!strcmp(arg, "--short") ||
git-rev-parse: Fix --short= option parsing Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
2006-02-18 04:10:53 +03:00
!strncmp(arg, "--short=", 8)) {
rev-parse: --abbrev option. The new option behaves just like --verify, but outputs an abbreviated object name that is unique within the repository. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-25 12:35:38 +03:00
filter &= ~(DO_FLAGS|DO_NOREV);
verify = 1;
abbrev = DEFAULT_ABBREV;
git-rev-parse: Fix --short= option parsing Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
2006-02-18 04:10:53 +03:00
if (arg[7] == '=')
abbrev = strtoul(arg + 8, NULL, 10);
rev-parse --abbrev: do not try abbrev shorter than minimum. We do not allow abbreviation shorter than 4 letters in other parts of the system so do not attempt to generate such. Noticed by Uwe Zeisberger. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-26 11:48:19 +03:00
if (abbrev < MINIMUM_ABBREV)
abbrev = MINIMUM_ABBREV;
else if (40 <= abbrev)
abbrev = 40;
rev-parse: --abbrev option. The new option behaves just like --verify, but outputs an abbreviated object name that is unique within the repository. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-25 12:35:38 +03:00
continue;
}
[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>
2005-07-23 06:08:32 +04:00
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.
2005-06-26 22:34:30 +04:00
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>
2005-08-16 23:36:46 +04:00
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.
2005-07-04 00:07:52 +04:00
if (!strcmp(arg, "--all")) {
for_each_ref(show_reference);
continue;
}
Add "--branches", "--tags" and "--remotes" options to git-rev-parse. "git branch" uses "rev-parse --all" and becomes much too slow when there are many tags (it scans all refs). Use the new "--branches" option of rev-parse to speed things up. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-14 05:43:00 +04:00
if (!strcmp(arg, "--branches")) {
for_each_branch_ref(show_reference);
continue;
}
if (!strcmp(arg, "--tags")) {
for_each_tag_ref(show_reference);
continue;
}
if (!strcmp(arg, "--remotes")) {
for_each_remote_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>
2005-08-17 05:06:34 +04:00
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>
2005-08-25 01:30:04 +04:00
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>
2005-08-17 05:06:34 +04:00
continue;
}
rev-parse: --show-cdup When --show-prefix is useful, sometimes it is easier to cd up to the toplevel of the tree. This is equivalent to: git rev-parse --show-prefix | sed -e 's|[^/][^/]*|..|g' but we do not have to invoke sed for that. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-23 09:35:38 +03:00
if (!strcmp(arg, "--show-cdup")) {
const char *pfx = prefix;
while (pfx) {
pfx = strchr(pfx, '/');
if (pfx) {
pfx++;
printf("../");
}
}
putchar('\n');
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>
2005-09-18 22:18:30 +04:00
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>
2005-09-21 01:13:24 +04:00
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;
}
Fix git-rev-parse over-eager errors Using "--verify" together with "--no-flags" makes perfect sense, but git-rev-parse would complain about it when it saw a flag, even though it would never actually use/output that flag. This fixes it. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 22:58:34 +03:00
if (show_flag(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>
2005-08-25 01:30:04 +04:00
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.
2005-06-13 21:06:50 +04:00
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>
2005-08-25 01:30:04 +04:00
/* 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.
2005-06-13 21:06:50 +04:00
dotdot = strstr(arg, "..");
if (dotdot) {
unsigned char end[20];
revision arguments: ..B means HEAD..B, just like A.. means A..HEAD For consistency reasons, we should probably allow that to be written as just "..branch", the same way we can write "branch.." to mean "everything in HEAD but not in "branch". Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-30 07:41:37 +04:00
char *next = dotdot + 2;
char *this = 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 21:06:50 +04:00
*dotdot = 0;
revision arguments: ..B means HEAD..B, just like A.. means A..HEAD For consistency reasons, we should probably allow that to be written as just "..branch", the same way we can write "branch.." to mean "everything in HEAD but not in "branch". Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-30 07:41:37 +04:00
if (!*next)
next = "HEAD";
if (dotdot == arg)
this = "HEAD";
if (!get_sha1(this, sha1) && !get_sha1(next, end)) {
show_rev(NORMAL, end, next);
show_rev(REVERSED, sha1, this);
continue;
Add 'git-rev-parse' helper script It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13 21:06:50 +04:00
}
*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>
2005-08-04 09:15:49 +04:00
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>
2005-08-16 23:36:46 +04:00
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.
2005-06-20 19:29:13 +04:00
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>
2005-08-04 09:15:49 +04:00
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>
2005-08-16 23:36:46 +04:00
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.
2005-06-20 19:29:13 +04:00
continue;
}
rev-parse lstat() workaround cleanup. Earlier we had a workaround to avoid misspelled revision name to be taken as a filename when "--no-revs --no-flags" are in effect. This cleans up the logic. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06 08:41:47 +03:00
as_is = 1;
if (!show_file(arg))
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>
2005-08-25 01:30:04 +04:00
if (verify)
die("Needed a single revision");
Fix filename verification when in a subdirectory When we are in a subdirectory of a git archive, we need to take the prefix of that subdirectory into accoung when we verify filename arguments. Noted by Matthias Lederhofer This also uses the improved error reporting for all the other git commands that use the revision parsing interfaces, not just git-rev-parse. Also, it makes the error reporting for mixed filenames and argument flags clearer (you cannot put flags after the start of the pathname list). [jc: with fix to a trivial typo noticed by Timo Hirvonen] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-26 21:15:54 +04:00
verify_filename(prefix, 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 21:12:55 +04:00
}
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>
2005-08-25 01:30:04 +04:00
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.
2005-06-13 21:06:50 +04:00
return 0;
}