mirrors/git
0
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-24 10:26:17 +08:00
Code Issues Packages Projects Releases Wiki Activity
d925ffbd06
git/rev-list.c

179 lines
3.9 KiB
C
Raw Normal View History

Add "rev-list" program that uses the new time-based commit listing. This is probably what you'd want to see for "git log".
2005-04-24 10:04:40 +08:00
#include "cache.h"
#include "commit.h"
git-rev-list: use proper lazy reachability analysis This mean sthat you can give a beginning/end pair to git-rev-list, and it will show all entries that are reachable from the beginning but not the end. For example git-rev-list v2.6.12-rc5 v2.6.12-rc4 shows all commits that are in -rc5 but are not in -rc4.
2005-05-31 09:46:32 +08:00
#define SEEN (1u << 0)
#define INTERESTING (1u << 1)
#define UNINTERESTING (1u << 2)
git-rev-list: add "end" commit and "--header" flag The "end" commit is just faking it right now, it's sorting things purely by date, so this is _not_ a reachability analysis. Some day. The "--header" flag causes the commit message to be printed out, with a NUL character separator after it for parseability. This allows you to do things like use "grep -z" to grep for certain authors etc.
2005-05-26 09:29:09 +08:00
static const char rev_list_usage[] =
"usage: git-rev-list [OPTION] commit-id <commit-id>\n"
" --max-count=nr\n"
" --max-age=epoch\n"
" --min-age=epoch\n"
git-rev-list: add "--pretty" command line option That pretty-prints the resulting commit messages, so git-rev-list --pretty HEAD v2.6.12-rc5 | less -S basically ends up being a log of the changes between -rc5 and current head. It uses the pretty-printing helper function I just extracted from diff-tree.c.
2005-06-01 23:42:22 +08:00
" --header\n"
" --pretty";
git-rev-list: add "end" commit and "--header" flag The "end" commit is just faking it right now, it's sorting things purely by date, so this is _not_ a reachability analysis. Some day. The "--header" flag causes the commit message to be printed out, with a NUL character separator after it for parseability. This allows you to do things like use "grep -z" to grep for certain authors etc.
2005-05-26 09:29:09 +08:00
git-rev-list: factor out the commit printing from "main()" Functions that do many things are bad. We should basically just parse the arguments in main(). We're not quite there yet, but it's a step in the right direction.
2005-06-03 00:19:53 +08:00
static int verbose_header = 0;
static int show_parents = 0;
static int hdr_termination = 0;
static const char *prefix = "";
static unsigned long max_age = -1;
static unsigned long min_age = -1;
static int max_count = -1;
pretty_print_commit: add different formats You can ask to print out "raw" format (full headers, full body), "medium" format (author and date, full body) or "short" format (author only, condensed body). Use "git-rev-list --pretty=short HEAD | less -S" for an example.
2005-06-06 00:02:03 +08:00
static enum cmit_fmt commit_format = CMIT_FMT_RAW;
git-rev-list: factor out the commit printing from "main()" Functions that do many things are bad. We should basically just parse the arguments in main(). We're not quite there yet, but it's a step in the right direction.
2005-06-03 00:19:53 +08:00
static void show_commit(struct commit *commit)
{
printf("%s%s", prefix, sha1_to_hex(commit->object.sha1));
if (show_parents) {
struct commit_list *parents = commit->parents;
while (parents) {
printf(" %s", sha1_to_hex(parents->item->object.sha1));
parents = parents->next;
}
}
putchar('\n');
if (verbose_header) {
pretty_print_commit: add different formats You can ask to print out "raw" format (full headers, full body), "medium" format (author and date, full body) or "short" format (author only, condensed body). Use "git-rev-list --pretty=short HEAD | less -S" for an example.
2005-06-06 00:02:03 +08:00
static char pretty_header[16384];
pretty_print_commit(commit_format, commit->buffer, ~0, pretty_header, sizeof(pretty_header));
printf("%s%c", pretty_header, hdr_termination);
git-rev-list: factor out the commit printing from "main()" Functions that do many things are bad. We should basically just parse the arguments in main(). We're not quite there yet, but it's a step in the right direction.
2005-06-03 00:19:53 +08:00
}
}
static void show_commit_list(struct commit_list *list)
{
while (list) {
struct commit *commit = pop_most_recent_commit(&list, SEEN);
if (commit->object.flags & UNINTERESTING)
continue;
if (min_age != -1 && (commit->date > min_age))
continue;
if (max_age != -1 && (commit->date < max_age))
break;
if (max_count != -1 && !max_count--)
break;
show_commit(commit);
}
}
git-rev-list: use proper lazy reachability analysis This mean sthat you can give a beginning/end pair to git-rev-list, and it will show all entries that are reachable from the beginning but not the end. For example git-rev-list v2.6.12-rc5 v2.6.12-rc4 shows all commits that are in -rc5 but are not in -rc4.
2005-05-31 09:46:32 +08:00
static void mark_parents_uninteresting(struct commit *commit)
{
struct commit_list *parents = commit->parents;
while (parents) {
struct commit *commit = parents->item;
commit->object.flags |= UNINTERESTING;
parents = parents->next;
}
}
static int everybody_uninteresting(struct commit_list *list)
{
while (list) {
struct commit *commit = list->item;
list = list->next;
if (commit->object.flags & UNINTERESTING)
continue;
return 0;
}
return 1;
}
git-rev-list: allow arbitrary head selections, use git-rev-tree syntax This makes git-rev-list use the same command line syntax to mark the commits as git-rev-tree does, and instead of just allowing a start and end commit, it allows an arbitrary list of "interesting" and "uninteresting" commits. For example, imagine that you had three branches (a, b and c) that you are interested in, but you don't want to see stuff that already exists in another persons three releases (x, y and z). You can do git-rev-list a b c ^x ^y ^z (order doesn't matter, btw - feel free to put the uninteresting ones first or otherwise swithc them around), and it will show all the commits that are reachable from a/b/c but not reachable from x/y/z. The old syntax "git-rev-list start end" would not be written as "git-rev-list start ^end", or "git-rev-list ^end start". There's no limit to the number of heads you can specify (unlike git-rev-tree, which can handle a maximum of 16 heads).
2005-06-05 05:38:28 +08:00
struct commit_list *limit_list(struct commit_list *list)
git-rev-list: split out commit limiting from main() too. Ok, now I'm happier.
2005-06-03 00:25:44 +08:00
{
struct commit_list *newlist = NULL;
struct commit_list **p = &newlist;
do {
struct commit *commit = pop_most_recent_commit(&list, SEEN);
struct object *obj = &commit->object;
git-rev-list: allow arbitrary head selections, use git-rev-tree syntax This makes git-rev-list use the same command line syntax to mark the commits as git-rev-tree does, and instead of just allowing a start and end commit, it allows an arbitrary list of "interesting" and "uninteresting" commits. For example, imagine that you had three branches (a, b and c) that you are interested in, but you don't want to see stuff that already exists in another persons three releases (x, y and z). You can do git-rev-list a b c ^x ^y ^z (order doesn't matter, btw - feel free to put the uninteresting ones first or otherwise swithc them around), and it will show all the commits that are reachable from a/b/c but not reachable from x/y/z. The old syntax "git-rev-list start end" would not be written as "git-rev-list start ^end", or "git-rev-list ^end start". There's no limit to the number of heads you can specify (unlike git-rev-tree, which can handle a maximum of 16 heads).
2005-06-05 05:38:28 +08:00
if (obj->flags & UNINTERESTING) {
git-rev-list: split out commit limiting from main() too. Ok, now I'm happier.
2005-06-03 00:25:44 +08:00
mark_parents_uninteresting(commit);
if (everybody_uninteresting(list))
break;
continue;
}
p = &commit_list_insert(commit, p)->next;
} while (list);
return newlist;
}
pretty_print_commit: add different formats You can ask to print out "raw" format (full headers, full body), "medium" format (author and date, full body) or "short" format (author only, condensed body). Use "git-rev-list --pretty=short HEAD | less -S" for an example.
2005-06-06 00:02:03 +08:00
static enum cmit_fmt get_commit_format(const char *arg)
{
if (!*arg)
return CMIT_FMT_DEFAULT;
if (!strcmp(arg, "=raw"))
return CMIT_FMT_RAW;
if (!strcmp(arg, "=medium"))
return CMIT_FMT_MEDIUM;
if (!strcmp(arg, "=short"))
return CMIT_FMT_SHORT;
usage(rev_list_usage);
}
Add "rev-list" program that uses the new time-based commit listing. This is probably what you'd want to see for "git log".
2005-04-24 10:04:40 +08:00
int main(int argc, char **argv)
{
struct commit_list *list = NULL;
git-rev-list: allow arbitrary head selections, use git-rev-tree syntax This makes git-rev-list use the same command line syntax to mark the commits as git-rev-tree does, and instead of just allowing a start and end commit, it allows an arbitrary list of "interesting" and "uninteresting" commits. For example, imagine that you had three branches (a, b and c) that you are interested in, but you don't want to see stuff that already exists in another persons three releases (x, y and z). You can do git-rev-list a b c ^x ^y ^z (order doesn't matter, btw - feel free to put the uninteresting ones first or otherwise swithc them around), and it will show all the commits that are reachable from a/b/c but not reachable from x/y/z. The old syntax "git-rev-list start end" would not be written as "git-rev-list start ^end", or "git-rev-list ^end start". There's no limit to the number of heads you can specify (unlike git-rev-tree, which can handle a maximum of 16 heads).
2005-06-05 05:38:28 +08:00
int i, limited = 0;
Add "rev-list" program that uses the new time-based commit listing. This is probably what you'd want to see for "git log".
2005-04-24 10:04:40 +08:00
[PATCH] control/limit output of git-rev-list gitweb.cgi's default view is the log of the last day and git-rev-list can stop crawling the whole repo if we have all our data to display in the browser. Also the rss-feed query needs only the last 20 items. This will speeds up these queries dramatically. usage: rev-list [OPTION] commit-id --max-count=nr --max-age=epoch --min-age=epoch Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-06 16:00:11 +08:00
for (i = 1 ; i < argc; i++) {
git-rev-list: allow arbitrary head selections, use git-rev-tree syntax This makes git-rev-list use the same command line syntax to mark the commits as git-rev-tree does, and instead of just allowing a start and end commit, it allows an arbitrary list of "interesting" and "uninteresting" commits. For example, imagine that you had three branches (a, b and c) that you are interested in, but you don't want to see stuff that already exists in another persons three releases (x, y and z). You can do git-rev-list a b c ^x ^y ^z (order doesn't matter, btw - feel free to put the uninteresting ones first or otherwise swithc them around), and it will show all the commits that are reachable from a/b/c but not reachable from x/y/z. The old syntax "git-rev-list start end" would not be written as "git-rev-list start ^end", or "git-rev-list ^end start". There's no limit to the number of heads you can specify (unlike git-rev-tree, which can handle a maximum of 16 heads).
2005-06-05 05:38:28 +08:00
int flags;
[PATCH] control/limit output of git-rev-list gitweb.cgi's default view is the log of the last day and git-rev-list can stop crawling the whole repo if we have all our data to display in the browser. Also the rss-feed query needs only the last 20 items. This will speeds up these queries dramatically. usage: rev-list [OPTION] commit-id --max-count=nr --max-age=epoch --min-age=epoch Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-06 16:00:11 +08:00
char *arg = argv[i];
git-rev-list: allow arbitrary head selections, use git-rev-tree syntax This makes git-rev-list use the same command line syntax to mark the commits as git-rev-tree does, and instead of just allowing a start and end commit, it allows an arbitrary list of "interesting" and "uninteresting" commits. For example, imagine that you had three branches (a, b and c) that you are interested in, but you don't want to see stuff that already exists in another persons three releases (x, y and z). You can do git-rev-list a b c ^x ^y ^z (order doesn't matter, btw - feel free to put the uninteresting ones first or otherwise swithc them around), and it will show all the commits that are reachable from a/b/c but not reachable from x/y/z. The old syntax "git-rev-list start end" would not be written as "git-rev-list start ^end", or "git-rev-list ^end start". There's no limit to the number of heads you can specify (unlike git-rev-tree, which can handle a maximum of 16 heads).
2005-06-05 05:38:28 +08:00
unsigned char sha1[20];
struct commit *commit;
[PATCH] control/limit output of git-rev-list gitweb.cgi's default view is the log of the last day and git-rev-list can stop crawling the whole repo if we have all our data to display in the browser. Also the rss-feed query needs only the last 20 items. This will speeds up these queries dramatically. usage: rev-list [OPTION] commit-id --max-count=nr --max-age=epoch --min-age=epoch Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-06 16:00:11 +08:00
if (!strncmp(arg, "--max-count=", 12)) {
max_count = atoi(arg + 12);
git-rev-list: add "end" commit and "--header" flag The "end" commit is just faking it right now, it's sorting things purely by date, so this is _not_ a reachability analysis. Some day. The "--header" flag causes the commit message to be printed out, with a NUL character separator after it for parseability. This allows you to do things like use "grep -z" to grep for certain authors etc.
2005-05-26 09:29:09 +08:00
continue;
}
if (!strncmp(arg, "--max-age=", 10)) {
[PATCH] control/limit output of git-rev-list gitweb.cgi's default view is the log of the last day and git-rev-list can stop crawling the whole repo if we have all our data to display in the browser. Also the rss-feed query needs only the last 20 items. This will speeds up these queries dramatically. usage: rev-list [OPTION] commit-id --max-count=nr --max-age=epoch --min-age=epoch Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-06 16:00:11 +08:00
max_age = atoi(arg + 10);
git-rev-list: add "end" commit and "--header" flag The "end" commit is just faking it right now, it's sorting things purely by date, so this is _not_ a reachability analysis. Some day. The "--header" flag causes the commit message to be printed out, with a NUL character separator after it for parseability. This allows you to do things like use "grep -z" to grep for certain authors etc.
2005-05-26 09:29:09 +08:00
continue;
}
if (!strncmp(arg, "--min-age=", 10)) {
[PATCH] control/limit output of git-rev-list gitweb.cgi's default view is the log of the last day and git-rev-list can stop crawling the whole repo if we have all our data to display in the browser. Also the rss-feed query needs only the last 20 items. This will speeds up these queries dramatically. usage: rev-list [OPTION] commit-id --max-count=nr --max-age=epoch --min-age=epoch Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-06 16:00:11 +08:00
min_age = atoi(arg + 10);
git-rev-list: add "end" commit and "--header" flag The "end" commit is just faking it right now, it's sorting things purely by date, so this is _not_ a reachability analysis. Some day. The "--header" flag causes the commit message to be printed out, with a NUL character separator after it for parseability. This allows you to do things like use "grep -z" to grep for certain authors etc.
2005-05-26 09:29:09 +08:00
continue;
[PATCH] control/limit output of git-rev-list gitweb.cgi's default view is the log of the last day and git-rev-list can stop crawling the whole repo if we have all our data to display in the browser. Also the rss-feed query needs only the last 20 items. This will speeds up these queries dramatically. usage: rev-list [OPTION] commit-id --max-count=nr --max-age=epoch --min-age=epoch Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-06 16:00:11 +08:00
}
git-rev-list: add "end" commit and "--header" flag The "end" commit is just faking it right now, it's sorting things purely by date, so this is _not_ a reachability analysis. Some day. The "--header" flag causes the commit message to be printed out, with a NUL character separator after it for parseability. This allows you to do things like use "grep -z" to grep for certain authors etc.
2005-05-26 09:29:09 +08:00
if (!strcmp(arg, "--header")) {
verbose_header = 1;
continue;
}
pretty_print_commit: add different formats You can ask to print out "raw" format (full headers, full body), "medium" format (author and date, full body) or "short" format (author only, condensed body). Use "git-rev-list --pretty=short HEAD | less -S" for an example.
2005-06-06 00:02:03 +08:00
if (!strncmp(arg, "--pretty", 8)) {
commit_format = get_commit_format(arg+8);
git-rev-list: add "--pretty" command line option That pretty-prints the resulting commit messages, so git-rev-list --pretty HEAD v2.6.12-rc5 | less -S basically ends up being a log of the changes between -rc5 and current head. It uses the pretty-printing helper function I just extracted from diff-tree.c.
2005-06-01 23:42:22 +08:00
verbose_header = 1;
hdr_termination = '\n';
prefix = "commit ";
continue;
}
git-rev-list: add "--parents" command line flag It makes rev-list show the list of parents, the same way git-rev-tree does (but without the expense).
2005-05-31 10:30:07 +08:00
if (!strcmp(arg, "--parents")) {
show_parents = 1;
continue;
}
git-rev-list: add "end" commit and "--header" flag The "end" commit is just faking it right now, it's sorting things purely by date, so this is _not_ a reachability analysis. Some day. The "--header" flag causes the commit message to be printed out, with a NUL character separator after it for parseability. This allows you to do things like use "grep -z" to grep for certain authors etc.
2005-05-26 09:29:09 +08:00
git-rev-list: allow arbitrary head selections, use git-rev-tree syntax This makes git-rev-list use the same command line syntax to mark the commits as git-rev-tree does, and instead of just allowing a start and end commit, it allows an arbitrary list of "interesting" and "uninteresting" commits. For example, imagine that you had three branches (a, b and c) that you are interested in, but you don't want to see stuff that already exists in another persons three releases (x, y and z). You can do git-rev-list a b c ^x ^y ^z (order doesn't matter, btw - feel free to put the uninteresting ones first or otherwise swithc them around), and it will show all the commits that are reachable from a/b/c but not reachable from x/y/z. The old syntax "git-rev-list start end" would not be written as "git-rev-list start ^end", or "git-rev-list ^end start". There's no limit to the number of heads you can specify (unlike git-rev-tree, which can handle a maximum of 16 heads).
2005-06-05 05:38:28 +08:00
flags = 0;
if (*arg == '^') {
flags = UNINTERESTING;
arg++;
limited = 1;
}
if (get_sha1(arg, sha1))
git-rev-list: add "end" commit and "--header" flag The "end" commit is just faking it right now, it's sorting things purely by date, so this is _not_ a reachability analysis. Some day. The "--header" flag causes the commit message to be printed out, with a NUL character separator after it for parseability. This allows you to do things like use "grep -z" to grep for certain authors etc.
2005-05-26 09:29:09 +08:00
usage(rev_list_usage);
git-rev-list: allow arbitrary head selections, use git-rev-tree syntax This makes git-rev-list use the same command line syntax to mark the commits as git-rev-tree does, and instead of just allowing a start and end commit, it allows an arbitrary list of "interesting" and "uninteresting" commits. For example, imagine that you had three branches (a, b and c) that you are interested in, but you don't want to see stuff that already exists in another persons three releases (x, y and z). You can do git-rev-list a b c ^x ^y ^z (order doesn't matter, btw - feel free to put the uninteresting ones first or otherwise swithc them around), and it will show all the commits that are reachable from a/b/c but not reachable from x/y/z. The old syntax "git-rev-list start end" would not be written as "git-rev-list start ^end", or "git-rev-list ^end start". There's no limit to the number of heads you can specify (unlike git-rev-tree, which can handle a maximum of 16 heads).
2005-06-05 05:38:28 +08:00
commit = lookup_commit_reference(sha1);
if (!commit || parse_commit(commit) < 0)
die("bad commit object %s", arg);
commit->object.flags |= flags;
commit_list_insert(commit, &list);
[PATCH] control/limit output of git-rev-list gitweb.cgi's default view is the log of the last day and git-rev-list can stop crawling the whole repo if we have all our data to display in the browser. Also the rss-feed query needs only the last 20 items. This will speeds up these queries dramatically. usage: rev-list [OPTION] commit-id --max-count=nr --max-age=epoch --min-age=epoch Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-06 16:00:11 +08:00
}
git-rev-list: allow arbitrary head selections, use git-rev-tree syntax This makes git-rev-list use the same command line syntax to mark the commits as git-rev-tree does, and instead of just allowing a start and end commit, it allows an arbitrary list of "interesting" and "uninteresting" commits. For example, imagine that you had three branches (a, b and c) that you are interested in, but you don't want to see stuff that already exists in another persons three releases (x, y and z). You can do git-rev-list a b c ^x ^y ^z (order doesn't matter, btw - feel free to put the uninteresting ones first or otherwise swithc them around), and it will show all the commits that are reachable from a/b/c but not reachable from x/y/z. The old syntax "git-rev-list start end" would not be written as "git-rev-list start ^end", or "git-rev-list ^end start". There's no limit to the number of heads you can specify (unlike git-rev-tree, which can handle a maximum of 16 heads).
2005-06-05 05:38:28 +08:00
if (!list)
git-rev-list: add "end" commit and "--header" flag The "end" commit is just faking it right now, it's sorting things purely by date, so this is _not_ a reachability analysis. Some day. The "--header" flag causes the commit message to be printed out, with a NUL character separator after it for parseability. This allows you to do things like use "grep -z" to grep for certain authors etc.
2005-05-26 09:29:09 +08:00
usage(rev_list_usage);
Add "rev-list" program that uses the new time-based commit listing. This is probably what you'd want to see for "git log".
2005-04-24 10:04:40 +08:00
git-rev-list: allow arbitrary head selections, use git-rev-tree syntax This makes git-rev-list use the same command line syntax to mark the commits as git-rev-tree does, and instead of just allowing a start and end commit, it allows an arbitrary list of "interesting" and "uninteresting" commits. For example, imagine that you had three branches (a, b and c) that you are interested in, but you don't want to see stuff that already exists in another persons three releases (x, y and z). You can do git-rev-list a b c ^x ^y ^z (order doesn't matter, btw - feel free to put the uninteresting ones first or otherwise swithc them around), and it will show all the commits that are reachable from a/b/c but not reachable from x/y/z. The old syntax "git-rev-list start end" would not be written as "git-rev-list start ^end", or "git-rev-list ^end start". There's no limit to the number of heads you can specify (unlike git-rev-tree, which can handle a maximum of 16 heads).
2005-06-05 05:38:28 +08:00
if (limited)
list = limit_list(list);
git-rev-list: use proper lazy reachability analysis This mean sthat you can give a beginning/end pair to git-rev-list, and it will show all entries that are reachable from the beginning but not the end. For example git-rev-list v2.6.12-rc5 v2.6.12-rc4 shows all commits that are in -rc5 but are not in -rc4.
2005-05-31 09:46:32 +08:00
git-rev-list: factor out the commit printing from "main()" Functions that do many things are bad. We should basically just parse the arguments in main(). We're not quite there yet, but it's a step in the right direction.
2005-06-03 00:19:53 +08:00
show_commit_list(list);
Add "rev-list" program that uses the new time-based commit listing. This is probably what you'd want to see for "git log".
2005-04-24 10:04:40 +08:00
return 0;
}
Reference in New Issue Copy Permalink