Retire rev-tree.
Some old scripts might still use git-rev-tree, but it really is clearly inferior in every way to git-rev-list that such scripts should be fixed anyway. Fixing them should be pretty easy. Signed-off-by: Junio C Hamano <junkio@cox.net>maint
parent
0fe51391a8
commit
9dcc829fe1
|
@ -69,7 +69,6 @@ git-reset
|
||||||
git-resolve
|
git-resolve
|
||||||
git-rev-list
|
git-rev-list
|
||||||
git-rev-parse
|
git-rev-parse
|
||||||
git-rev-tree
|
|
||||||
git-revert
|
git-revert
|
||||||
git-send-email
|
git-send-email
|
||||||
git-send-pack
|
git-send-pack
|
||||||
|
|
|
@ -1,88 +0,0 @@
|
||||||
git-rev-tree(1)
|
|
||||||
===============
|
|
||||||
v0.1, May 2005
|
|
||||||
|
|
||||||
NAME
|
|
||||||
----
|
|
||||||
git-rev-tree - Provides the revision tree for one or more commits
|
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
|
||||||
--------
|
|
||||||
'git-rev-tree' [--edges] [--cache <cache-file>] [^]<commit> [[^]<commit>]
|
|
||||||
|
|
||||||
DESCRIPTION
|
|
||||||
-----------
|
|
||||||
Provides the revision tree for one or more commits.
|
|
||||||
|
|
||||||
OPTIONS
|
|
||||||
-------
|
|
||||||
--edges::
|
|
||||||
Show edges (ie places where the marking changes between parent
|
|
||||||
and child)
|
|
||||||
|
|
||||||
--cache <cache-file>::
|
|
||||||
Use the specified file as a cache from a previous git-rev-list run
|
|
||||||
to speed things up. Note that this "cache" is totally different
|
|
||||||
concept from the directory index. Also this option is not
|
|
||||||
implemented yet.
|
|
||||||
|
|
||||||
[^]<commit>::
|
|
||||||
The commit id to trace (a leading caret means to ignore this
|
|
||||||
commit-id and below)
|
|
||||||
|
|
||||||
Output
|
|
||||||
------
|
|
||||||
|
|
||||||
<date> <commit>:<flags> [<parent-commit>:<flags> ]\*
|
|
||||||
|
|
||||||
<date>::
|
|
||||||
Date in 'seconds since epoch'
|
|
||||||
|
|
||||||
<commit>::
|
|
||||||
id of commit object
|
|
||||||
|
|
||||||
<parent-commit>::
|
|
||||||
id of each parent commit object (>1 indicates a merge)
|
|
||||||
|
|
||||||
<flags>::
|
|
||||||
|
|
||||||
The flags are read as a bitmask representing each commit
|
|
||||||
provided on the commandline. eg: given the command:
|
|
||||||
|
|
||||||
$ git-rev-tree <com1> <com2> <com3>
|
|
||||||
|
|
||||||
The output:
|
|
||||||
|
|
||||||
<date> <commit>:5
|
|
||||||
|
|
||||||
means that <commit> is reachable from <com1>(1) and <com3>(4)
|
|
||||||
|
|
||||||
A revtree can get quite large. "git-rev-tree" will eventually allow
|
|
||||||
you to cache previous state so that you don't have to follow the whole
|
|
||||||
thing down.
|
|
||||||
|
|
||||||
So the change difference between two commits is literally
|
|
||||||
|
|
||||||
git-rev-tree [commit-id1] > commit1-revtree
|
|
||||||
git-rev-tree [commit-id2] > commit2-revtree
|
|
||||||
join -t : commit1-revtree commit2-revtree > common-revisions
|
|
||||||
|
|
||||||
(this is also how to find the most common parent - you'd look at just
|
|
||||||
the head revisions - the ones that aren't referred to by other
|
|
||||||
revisions - in "common-revision", and figure out the best one. I
|
|
||||||
think.)
|
|
||||||
|
|
||||||
|
|
||||||
Author
|
|
||||||
------
|
|
||||||
Written by Linus Torvalds <torvalds@osdl.org>
|
|
||||||
|
|
||||||
Documentation
|
|
||||||
--------------
|
|
||||||
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
|
|
||||||
|
|
||||||
GIT
|
|
||||||
---
|
|
||||||
Part of the gitlink:git[7] suite
|
|
||||||
|
|
|
@ -134,9 +134,6 @@ gitlink:git-merge-base[1]::
|
||||||
gitlink:git-rev-list[1]::
|
gitlink:git-rev-list[1]::
|
||||||
Lists commit objects in reverse chronological order
|
Lists commit objects in reverse chronological order
|
||||||
|
|
||||||
gitlink:git-rev-tree[1]::
|
|
||||||
Provides the revision tree for one or more commits
|
|
||||||
|
|
||||||
gitlink:git-show-index[1]::
|
gitlink:git-show-index[1]::
|
||||||
Displays contents of a pack idx file.
|
Displays contents of a pack idx file.
|
||||||
|
|
||||||
|
|
|
@ -245,7 +245,7 @@ gb=$(tput setab 2)
|
||||||
rb=$(tput setab 1)
|
rb=$(tput setab 1)
|
||||||
restore=$(tput setab 9)
|
restore=$(tput setab 9)
|
||||||
|
|
||||||
if [ `git-rev-tree release ^test | wc -c` -gt 0 ]
|
if [ `git-rev-list release ^test | wc -c` -gt 0 ]
|
||||||
then
|
then
|
||||||
echo $rb Warning: commits in release that are not in test $restore
|
echo $rb Warning: commits in release that are not in test $restore
|
||||||
git-whatchanged release ^test
|
git-whatchanged release ^test
|
||||||
|
@ -262,7 +262,7 @@ do
|
||||||
status=
|
status=
|
||||||
for ref in test release linus
|
for ref in test release linus
|
||||||
do
|
do
|
||||||
if [ `git-rev-tree $branch ^$ref | wc -c` -gt 0 ]
|
if [ `git-rev-list $branch ^$ref | wc -c` -gt 0 ]
|
||||||
then
|
then
|
||||||
status=$status${ref:0:1}
|
status=$status${ref:0:1}
|
||||||
fi
|
fi
|
||||||
|
|
2
Makefile
2
Makefile
|
@ -109,7 +109,7 @@ PROGRAMS = \
|
||||||
git-merge-index git-mktag git-pack-objects git-patch-id \
|
git-merge-index git-mktag git-pack-objects git-patch-id \
|
||||||
git-peek-remote git-prune-packed git-read-tree \
|
git-peek-remote git-prune-packed git-read-tree \
|
||||||
git-receive-pack git-rev-list git-rev-parse \
|
git-receive-pack git-rev-list git-rev-parse \
|
||||||
git-rev-tree git-send-pack git-show-branch \
|
git-send-pack git-show-branch \
|
||||||
git-show-index git-ssh-fetch \
|
git-show-index git-ssh-fetch \
|
||||||
git-ssh-upload git-tar-tree git-unpack-file \
|
git-ssh-upload git-tar-tree git-unpack-file \
|
||||||
git-unpack-objects git-update-index git-update-server-info \
|
git-unpack-objects git-update-index git-update-server-info \
|
||||||
|
|
140
rev-tree.c
140
rev-tree.c
|
@ -1,140 +0,0 @@
|
||||||
#include "cache.h"
|
|
||||||
#include "commit.h"
|
|
||||||
|
|
||||||
/*
|
|
||||||
* revision.h leaves the low 16 bits of the "flags" field of the
|
|
||||||
* revision data structure unused. We use it for a "reachable from
|
|
||||||
* this commit <N>" bitmask.
|
|
||||||
*/
|
|
||||||
#define MAX_COMMITS 16
|
|
||||||
#define REACHABLE (1U << 16)
|
|
||||||
|
|
||||||
#define cmit_flags(cmit) ((cmit)->object.flags & ~REACHABLE)
|
|
||||||
|
|
||||||
static int show_edges = 0;
|
|
||||||
static int basemask = 0;
|
|
||||||
|
|
||||||
static void read_cache_file(const char *path)
|
|
||||||
{
|
|
||||||
die("no revtree cache file yet");
|
|
||||||
}
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Some revisions are less interesting than others.
|
|
||||||
*
|
|
||||||
* For example, if we use a cache-file, that one may contain
|
|
||||||
* revisions that were never used. They are never interesting.
|
|
||||||
*
|
|
||||||
* And sometimes we're only interested in "edge" commits, ie
|
|
||||||
* places where the marking changes between parent and child.
|
|
||||||
*/
|
|
||||||
static int interesting(struct commit *rev)
|
|
||||||
{
|
|
||||||
unsigned mask = cmit_flags(rev);
|
|
||||||
|
|
||||||
if (!mask)
|
|
||||||
return 0;
|
|
||||||
if (show_edges) {
|
|
||||||
struct commit_list *p = rev->parents;
|
|
||||||
while (p) {
|
|
||||||
if (mask != cmit_flags(p->item))
|
|
||||||
return 1;
|
|
||||||
p = p->next;
|
|
||||||
}
|
|
||||||
return 0;
|
|
||||||
}
|
|
||||||
if (mask & basemask)
|
|
||||||
return 0;
|
|
||||||
|
|
||||||
return 1;
|
|
||||||
}
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Usage: git-rev-tree [--edges] [--cache <cache-file>] <commit-id> [<commit-id2>]
|
|
||||||
*
|
|
||||||
* The cache-file can be quite important for big trees. This is an
|
|
||||||
* expensive operation if you have to walk the whole chain of
|
|
||||||
* parents in a tree with a long revision history.
|
|
||||||
*/
|
|
||||||
int main(int argc, char **argv)
|
|
||||||
{
|
|
||||||
int i;
|
|
||||||
int nr = 0;
|
|
||||||
unsigned char sha1[MAX_COMMITS][20];
|
|
||||||
struct commit_list *list = NULL;
|
|
||||||
|
|
||||||
/*
|
|
||||||
* First - pick up all the revisions we can (both from
|
|
||||||
* caches and from commit file chains).
|
|
||||||
*/
|
|
||||||
for (i = 1; i < argc ; i++) {
|
|
||||||
char *arg = argv[i];
|
|
||||||
struct commit *commit;
|
|
||||||
|
|
||||||
if (!strcmp(arg, "--cache")) {
|
|
||||||
read_cache_file(argv[++i]);
|
|
||||||
continue;
|
|
||||||
}
|
|
||||||
|
|
||||||
if (!strcmp(arg, "--edges")) {
|
|
||||||
show_edges = 1;
|
|
||||||
continue;
|
|
||||||
}
|
|
||||||
|
|
||||||
if (arg[0] == '^') {
|
|
||||||
arg++;
|
|
||||||
basemask |= 1<<nr;
|
|
||||||
}
|
|
||||||
if (nr >= MAX_COMMITS || get_sha1(arg, sha1[nr]))
|
|
||||||
usage("git-rev-tree [--edges] [--cache <cache-file>] <commit-id> [<commit-id>]");
|
|
||||||
|
|
||||||
commit = lookup_commit_reference(sha1[nr]);
|
|
||||||
if (!commit || parse_commit(commit) < 0)
|
|
||||||
die("bad commit object");
|
|
||||||
commit_list_insert(commit, &list);
|
|
||||||
nr++;
|
|
||||||
}
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Parse all the commits in date order.
|
|
||||||
*
|
|
||||||
* We really should stop once we know enough, but that's a
|
|
||||||
* decision that isn't trivial to make.
|
|
||||||
*/
|
|
||||||
while (list)
|
|
||||||
pop_most_recent_commit(&list, REACHABLE);
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Now we have the maximal tree. Walk the different sha files back to the root.
|
|
||||||
*/
|
|
||||||
for (i = 0; i < nr; i++)
|
|
||||||
mark_reachable(&lookup_commit_reference(sha1[i])->object, 1 << i);
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Now print out the results..
|
|
||||||
*/
|
|
||||||
for (i = 0; i < nr_objs; i++) {
|
|
||||||
struct object *obj = objs[i];
|
|
||||||
struct commit *commit;
|
|
||||||
struct commit_list *p;
|
|
||||||
|
|
||||||
if (obj->type != commit_type)
|
|
||||||
continue;
|
|
||||||
|
|
||||||
commit = (struct commit *) obj;
|
|
||||||
|
|
||||||
if (!interesting(commit))
|
|
||||||
continue;
|
|
||||||
|
|
||||||
printf("%lu %s:%d", commit->date, sha1_to_hex(obj->sha1),
|
|
||||||
cmit_flags(commit));
|
|
||||||
p = commit->parents;
|
|
||||||
while (p) {
|
|
||||||
printf(" %s:%d", sha1_to_hex(p->item->object.sha1),
|
|
||||||
cmit_flags(p->item));
|
|
||||||
p = p->next;
|
|
||||||
}
|
|
||||||
printf("\n");
|
|
||||||
}
|
|
||||||
return 0;
|
|
||||||
}
|
|
Loading…
Reference in New Issue