2006-02-26 01:19:46 +01:00
|
|
|
#include "cache.h"
|
|
|
|
#include "tag.h"
|
|
|
|
#include "blob.h"
|
|
|
|
#include "tree.h"
|
|
|
|
#include "commit.h"
|
2006-02-28 20:24:00 +01:00
|
|
|
#include "diff.h"
|
2006-02-26 01:19:46 +01:00
|
|
|
#include "refs.h"
|
|
|
|
#include "revision.h"
|
|
|
|
|
|
|
|
static char *path_name(struct name_path *path, const char *name)
|
|
|
|
{
|
|
|
|
struct name_path *p;
|
|
|
|
char *n, *m;
|
|
|
|
int nlen = strlen(name);
|
|
|
|
int len = nlen + 1;
|
|
|
|
|
|
|
|
for (p = path; p; p = p->up) {
|
|
|
|
if (p->elem_len)
|
|
|
|
len += p->elem_len + 1;
|
|
|
|
}
|
|
|
|
n = xmalloc(len);
|
|
|
|
m = n + len - (nlen + 1);
|
|
|
|
strcpy(m, name);
|
|
|
|
for (p = path; p; p = p->up) {
|
|
|
|
if (p->elem_len) {
|
|
|
|
m -= p->elem_len + 1;
|
|
|
|
memcpy(m, p->elem, p->elem_len);
|
|
|
|
m[p->elem_len] = '/';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
Add "named object array" concept
We've had this notion of a "object_list" for a long time, which eventually
grew a "name" member because some users (notably git-rev-list) wanted to
name each object as it is generated.
That object_list is great for some things, but it isn't all that wonderful
for others, and the "name" member is generally not used by everybody.
This patch splits the users of the object_list array up into two: the
traditional list users, who want the list-like format, and who don't
actually use or want the name. And another class of users that really used
the list as an extensible array, and generally wanted to name the objects.
The patch is fairly straightforward, but it's also biggish. Most of it
really just cleans things up: switching the revision parsing and listing
over to the array makes things like the builtin-diff usage much simpler
(we now see exactly how many members the array has, and we don't get the
objects reversed from the order they were on the command line).
One of the main reasons for doing this at all is that the malloc overhead
of the simple object list was actually pretty high, and the array is just
a lot denser. So this patch brings down memory usage by git-rev-list by
just under 3% (on top of all the other memory use optimizations) on the
mozilla archive.
It does add more lines than it removes, and more importantly, it adds a
whole new infrastructure for maintaining lists of objects, but on the
other hand, the new dynamic array code is pretty obvious. The change to
builtin-diff-tree.c shows a fairly good example of why an array interface
is sometimes more natural, and just much simpler for everybody.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-20 02:42:35 +02:00
|
|
|
void add_object(struct object *obj,
|
|
|
|
struct object_array *p,
|
|
|
|
struct name_path *path,
|
|
|
|
const char *name)
|
2006-02-26 01:19:46 +01:00
|
|
|
{
|
Add "named object array" concept
We've had this notion of a "object_list" for a long time, which eventually
grew a "name" member because some users (notably git-rev-list) wanted to
name each object as it is generated.
That object_list is great for some things, but it isn't all that wonderful
for others, and the "name" member is generally not used by everybody.
This patch splits the users of the object_list array up into two: the
traditional list users, who want the list-like format, and who don't
actually use or want the name. And another class of users that really used
the list as an extensible array, and generally wanted to name the objects.
The patch is fairly straightforward, but it's also biggish. Most of it
really just cleans things up: switching the revision parsing and listing
over to the array makes things like the builtin-diff usage much simpler
(we now see exactly how many members the array has, and we don't get the
objects reversed from the order they were on the command line).
One of the main reasons for doing this at all is that the malloc overhead
of the simple object list was actually pretty high, and the array is just
a lot denser. So this patch brings down memory usage by git-rev-list by
just under 3% (on top of all the other memory use optimizations) on the
mozilla archive.
It does add more lines than it removes, and more importantly, it adds a
whole new infrastructure for maintaining lists of objects, but on the
other hand, the new dynamic array code is pretty obvious. The change to
builtin-diff-tree.c shows a fairly good example of why an array interface
is sometimes more natural, and just much simpler for everybody.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-20 02:42:35 +02:00
|
|
|
add_object_array(obj, path_name(path, name), p);
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void mark_blob_uninteresting(struct blob *blob)
|
|
|
|
{
|
|
|
|
if (blob->object.flags & UNINTERESTING)
|
|
|
|
return;
|
|
|
|
blob->object.flags |= UNINTERESTING;
|
|
|
|
}
|
|
|
|
|
|
|
|
void mark_tree_uninteresting(struct tree *tree)
|
|
|
|
{
|
2006-05-29 21:20:14 +02:00
|
|
|
struct tree_desc desc;
|
tree_entry(): new tree-walking helper function
This adds a "tree_entry()" function that combines the common operation of
doing a "tree_entry_extract()" + "update_tree_entry()".
It also has a simplified calling convention, designed for simple loops
that traverse over a whole tree: the arguments are pointers to the tree
descriptor and a name_entry structure to fill in, and it returns a boolean
"true" if there was an entry left to be gotten in the tree.
This allows tree traversal with
struct tree_desc desc;
struct name_entry entry;
desc.buf = tree->buffer;
desc.size = tree->size;
while (tree_entry(&desc, &entry) {
... use "entry.{path, sha1, mode, pathlen}" ...
}
which is not only shorter than writing it out in full, it's hopefully less
error prone too.
[ It's actually a tad faster too - we don't need to recalculate the entry
pathlength in both extract and update, but need to do it only once.
Also, some callers can avoid doing a "strlen()" on the result, since
it's returned as part of the name_entry structure.
However, by now we're talking just 1% speedup on "git-rev-list --objects
--all", and we're definitely at the point where tree walking is no
longer the issue any more. ]
NOTE! Not everybody wants to use this new helper function, since some of
the tree walkers very much on purpose do the descriptor update separately
from the entry extraction. So the "extract + update" sequence still
remains as the core sequence, this is just a simplified interface.
We should probably add a silly two-line inline helper function for
initializing the descriptor from the "struct tree" too, just to cut down
on the noise from that common "desc" initializer.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-30 18:45:45 +02:00
|
|
|
struct name_entry entry;
|
2006-02-26 01:19:46 +01:00
|
|
|
struct object *obj = &tree->object;
|
|
|
|
|
|
|
|
if (obj->flags & UNINTERESTING)
|
|
|
|
return;
|
|
|
|
obj->flags |= UNINTERESTING;
|
|
|
|
if (!has_sha1_file(obj->sha1))
|
|
|
|
return;
|
|
|
|
if (parse_tree(tree) < 0)
|
|
|
|
die("bad tree %s", sha1_to_hex(obj->sha1));
|
2006-05-29 21:20:14 +02:00
|
|
|
|
|
|
|
desc.buf = tree->buffer;
|
|
|
|
desc.size = tree->size;
|
tree_entry(): new tree-walking helper function
This adds a "tree_entry()" function that combines the common operation of
doing a "tree_entry_extract()" + "update_tree_entry()".
It also has a simplified calling convention, designed for simple loops
that traverse over a whole tree: the arguments are pointers to the tree
descriptor and a name_entry structure to fill in, and it returns a boolean
"true" if there was an entry left to be gotten in the tree.
This allows tree traversal with
struct tree_desc desc;
struct name_entry entry;
desc.buf = tree->buffer;
desc.size = tree->size;
while (tree_entry(&desc, &entry) {
... use "entry.{path, sha1, mode, pathlen}" ...
}
which is not only shorter than writing it out in full, it's hopefully less
error prone too.
[ It's actually a tad faster too - we don't need to recalculate the entry
pathlength in both extract and update, but need to do it only once.
Also, some callers can avoid doing a "strlen()" on the result, since
it's returned as part of the name_entry structure.
However, by now we're talking just 1% speedup on "git-rev-list --objects
--all", and we're definitely at the point where tree walking is no
longer the issue any more. ]
NOTE! Not everybody wants to use this new helper function, since some of
the tree walkers very much on purpose do the descriptor update separately
from the entry extraction. So the "extract + update" sequence still
remains as the core sequence, this is just a simplified interface.
We should probably add a silly two-line inline helper function for
initializing the descriptor from the "struct tree" too, just to cut down
on the noise from that common "desc" initializer.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-30 18:45:45 +02:00
|
|
|
while (tree_entry(&desc, &entry)) {
|
|
|
|
if (S_ISDIR(entry.mode))
|
|
|
|
mark_tree_uninteresting(lookup_tree(entry.sha1));
|
2006-02-26 01:19:46 +01:00
|
|
|
else
|
tree_entry(): new tree-walking helper function
This adds a "tree_entry()" function that combines the common operation of
doing a "tree_entry_extract()" + "update_tree_entry()".
It also has a simplified calling convention, designed for simple loops
that traverse over a whole tree: the arguments are pointers to the tree
descriptor and a name_entry structure to fill in, and it returns a boolean
"true" if there was an entry left to be gotten in the tree.
This allows tree traversal with
struct tree_desc desc;
struct name_entry entry;
desc.buf = tree->buffer;
desc.size = tree->size;
while (tree_entry(&desc, &entry) {
... use "entry.{path, sha1, mode, pathlen}" ...
}
which is not only shorter than writing it out in full, it's hopefully less
error prone too.
[ It's actually a tad faster too - we don't need to recalculate the entry
pathlength in both extract and update, but need to do it only once.
Also, some callers can avoid doing a "strlen()" on the result, since
it's returned as part of the name_entry structure.
However, by now we're talking just 1% speedup on "git-rev-list --objects
--all", and we're definitely at the point where tree walking is no
longer the issue any more. ]
NOTE! Not everybody wants to use this new helper function, since some of
the tree walkers very much on purpose do the descriptor update separately
from the entry extraction. So the "extract + update" sequence still
remains as the core sequence, this is just a simplified interface.
We should probably add a silly two-line inline helper function for
initializing the descriptor from the "struct tree" too, just to cut down
on the noise from that common "desc" initializer.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-30 18:45:45 +02:00
|
|
|
mark_blob_uninteresting(lookup_blob(entry.sha1));
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
2006-05-29 21:20:14 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't care about the tree any more
|
|
|
|
* after it has been marked uninteresting.
|
|
|
|
*/
|
|
|
|
free(tree->buffer);
|
|
|
|
tree->buffer = NULL;
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void mark_parents_uninteresting(struct commit *commit)
|
|
|
|
{
|
|
|
|
struct commit_list *parents = commit->parents;
|
|
|
|
|
|
|
|
while (parents) {
|
|
|
|
struct commit *commit = parents->item;
|
2006-03-09 05:04:36 +01:00
|
|
|
if (!(commit->object.flags & UNINTERESTING)) {
|
|
|
|
commit->object.flags |= UNINTERESTING;
|
2006-02-26 01:19:46 +01:00
|
|
|
|
2006-03-09 05:04:36 +01:00
|
|
|
/*
|
|
|
|
* Normally we haven't parsed the parent
|
|
|
|
* yet, so we won't have a parent of a parent
|
|
|
|
* here. However, it may turn out that we've
|
|
|
|
* reached this commit some other way (where it
|
|
|
|
* wasn't uninteresting), in which case we need
|
|
|
|
* to mark its parents recursively too..
|
|
|
|
*/
|
|
|
|
if (commit->parents)
|
|
|
|
mark_parents_uninteresting(commit);
|
|
|
|
}
|
2006-02-26 01:19:46 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* A missing commit is ok iff its parent is marked
|
|
|
|
* uninteresting.
|
|
|
|
*
|
|
|
|
* We just mark such a thing parsed, so that when
|
|
|
|
* it is popped next time around, we won't be trying
|
|
|
|
* to parse it and get an error.
|
|
|
|
*/
|
|
|
|
if (!has_sha1_file(commit->object.sha1))
|
|
|
|
commit->object.parsed = 1;
|
|
|
|
parents = parents->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add "named object array" concept
We've had this notion of a "object_list" for a long time, which eventually
grew a "name" member because some users (notably git-rev-list) wanted to
name each object as it is generated.
That object_list is great for some things, but it isn't all that wonderful
for others, and the "name" member is generally not used by everybody.
This patch splits the users of the object_list array up into two: the
traditional list users, who want the list-like format, and who don't
actually use or want the name. And another class of users that really used
the list as an extensible array, and generally wanted to name the objects.
The patch is fairly straightforward, but it's also biggish. Most of it
really just cleans things up: switching the revision parsing and listing
over to the array makes things like the builtin-diff usage much simpler
(we now see exactly how many members the array has, and we don't get the
objects reversed from the order they were on the command line).
One of the main reasons for doing this at all is that the malloc overhead
of the simple object list was actually pretty high, and the array is just
a lot denser. So this patch brings down memory usage by git-rev-list by
just under 3% (on top of all the other memory use optimizations) on the
mozilla archive.
It does add more lines than it removes, and more importantly, it adds a
whole new infrastructure for maintaining lists of objects, but on the
other hand, the new dynamic array code is pretty obvious. The change to
builtin-diff-tree.c shows a fairly good example of why an array interface
is sometimes more natural, and just much simpler for everybody.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-20 02:42:35 +02:00
|
|
|
void add_pending_object(struct rev_info *revs, struct object *obj, const char *name)
|
2006-02-26 01:19:46 +01:00
|
|
|
{
|
Add "named object array" concept
We've had this notion of a "object_list" for a long time, which eventually
grew a "name" member because some users (notably git-rev-list) wanted to
name each object as it is generated.
That object_list is great for some things, but it isn't all that wonderful
for others, and the "name" member is generally not used by everybody.
This patch splits the users of the object_list array up into two: the
traditional list users, who want the list-like format, and who don't
actually use or want the name. And another class of users that really used
the list as an extensible array, and generally wanted to name the objects.
The patch is fairly straightforward, but it's also biggish. Most of it
really just cleans things up: switching the revision parsing and listing
over to the array makes things like the builtin-diff usage much simpler
(we now see exactly how many members the array has, and we don't get the
objects reversed from the order they were on the command line).
One of the main reasons for doing this at all is that the malloc overhead
of the simple object list was actually pretty high, and the array is just
a lot denser. So this patch brings down memory usage by git-rev-list by
just under 3% (on top of all the other memory use optimizations) on the
mozilla archive.
It does add more lines than it removes, and more importantly, it adds a
whole new infrastructure for maintaining lists of objects, but on the
other hand, the new dynamic array code is pretty obvious. The change to
builtin-diff-tree.c shows a fairly good example of why an array interface
is sometimes more natural, and just much simpler for everybody.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-20 02:42:35 +02:00
|
|
|
add_object_array(obj, name, &revs->pending);
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
|
|
|
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
static struct object *get_reference(struct rev_info *revs, const char *name, const unsigned char *sha1, unsigned int flags)
|
2006-02-26 01:19:46 +01:00
|
|
|
{
|
|
|
|
struct object *object;
|
|
|
|
|
|
|
|
object = parse_object(sha1);
|
|
|
|
if (!object)
|
|
|
|
die("bad object %s", name);
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
object->flags |= flags;
|
|
|
|
return object;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct commit *handle_commit(struct rev_info *revs, struct object *object, const char *name)
|
|
|
|
{
|
|
|
|
unsigned long flags = object->flags;
|
2006-02-26 01:19:46 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Tag object? Look what it points to..
|
|
|
|
*/
|
Shrink "struct object" a bit
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-15 01:45:13 +02:00
|
|
|
while (object->type == TYPE_TAG) {
|
2006-02-26 01:19:46 +01:00
|
|
|
struct tag *tag = (struct tag *) object;
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
if (revs->tag_objects && !(flags & UNINTERESTING))
|
2006-02-26 01:19:46 +01:00
|
|
|
add_pending_object(revs, object, tag->tag);
|
|
|
|
object = parse_object(tag->tagged->sha1);
|
|
|
|
if (!object)
|
|
|
|
die("bad object %s", sha1_to_hex(tag->tagged->sha1));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Commit object? Just return it, we'll do all the complex
|
|
|
|
* reachability crud.
|
|
|
|
*/
|
Shrink "struct object" a bit
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-15 01:45:13 +02:00
|
|
|
if (object->type == TYPE_COMMIT) {
|
2006-02-26 01:19:46 +01:00
|
|
|
struct commit *commit = (struct commit *)object;
|
|
|
|
if (parse_commit(commit) < 0)
|
|
|
|
die("unable to parse commit %s", name);
|
2006-02-27 17:54:36 +01:00
|
|
|
if (flags & UNINTERESTING) {
|
2006-04-19 05:31:41 +02:00
|
|
|
commit->object.flags |= UNINTERESTING;
|
2006-02-26 01:19:46 +01:00
|
|
|
mark_parents_uninteresting(commit);
|
2006-02-27 17:54:36 +01:00
|
|
|
revs->limited = 1;
|
|
|
|
}
|
2006-02-26 01:19:46 +01:00
|
|
|
return commit;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Tree object? Either mark it uniniteresting, or add it
|
|
|
|
* to the list of objects to look at later..
|
|
|
|
*/
|
Shrink "struct object" a bit
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-15 01:45:13 +02:00
|
|
|
if (object->type == TYPE_TREE) {
|
2006-02-26 01:19:46 +01:00
|
|
|
struct tree *tree = (struct tree *)object;
|
|
|
|
if (!revs->tree_objects)
|
|
|
|
return NULL;
|
|
|
|
if (flags & UNINTERESTING) {
|
|
|
|
mark_tree_uninteresting(tree);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
add_pending_object(revs, object, "");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Blob object? You know the drill by now..
|
|
|
|
*/
|
Shrink "struct object" a bit
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-15 01:45:13 +02:00
|
|
|
if (object->type == TYPE_BLOB) {
|
2006-02-26 01:19:46 +01:00
|
|
|
struct blob *blob = (struct blob *)object;
|
|
|
|
if (!revs->blob_objects)
|
|
|
|
return NULL;
|
|
|
|
if (flags & UNINTERESTING) {
|
|
|
|
mark_blob_uninteresting(blob);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
add_pending_object(revs, object, "");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
die("%s is unknown object", name);
|
|
|
|
}
|
|
|
|
|
2006-02-28 20:24:00 +01:00
|
|
|
static int everybody_uninteresting(struct commit_list *orig)
|
|
|
|
{
|
|
|
|
struct commit_list *list = orig;
|
|
|
|
while (list) {
|
|
|
|
struct commit *commit = list->item;
|
|
|
|
list = list->next;
|
|
|
|
if (commit->object.flags & UNINTERESTING)
|
|
|
|
continue;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2006-03-10 10:21:39 +01:00
|
|
|
static int tree_difference = REV_TREE_SAME;
|
2006-02-28 20:24:00 +01:00
|
|
|
|
|
|
|
static void file_add_remove(struct diff_options *options,
|
|
|
|
int addremove, unsigned mode,
|
|
|
|
const unsigned char *sha1,
|
|
|
|
const char *base, const char *path)
|
|
|
|
{
|
2006-03-10 10:21:39 +01:00
|
|
|
int diff = REV_TREE_DIFFERENT;
|
2006-02-28 20:24:00 +01:00
|
|
|
|
|
|
|
/*
|
2006-03-10 10:21:39 +01:00
|
|
|
* Is it an add of a new file? It means that the old tree
|
|
|
|
* didn't have it at all, so we will turn "REV_TREE_SAME" ->
|
|
|
|
* "REV_TREE_NEW", but leave any "REV_TREE_DIFFERENT" alone
|
|
|
|
* (and if it already was "REV_TREE_NEW", we'll keep it
|
|
|
|
* "REV_TREE_NEW" of course).
|
2006-02-28 20:24:00 +01:00
|
|
|
*/
|
|
|
|
if (addremove == '+') {
|
|
|
|
diff = tree_difference;
|
2006-03-10 10:21:39 +01:00
|
|
|
if (diff != REV_TREE_SAME)
|
2006-02-28 20:24:00 +01:00
|
|
|
return;
|
2006-03-10 10:21:39 +01:00
|
|
|
diff = REV_TREE_NEW;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
tree_difference = diff;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void file_change(struct diff_options *options,
|
|
|
|
unsigned old_mode, unsigned new_mode,
|
|
|
|
const unsigned char *old_sha1,
|
|
|
|
const unsigned char *new_sha1,
|
|
|
|
const char *base, const char *path)
|
|
|
|
{
|
2006-03-10 10:21:39 +01:00
|
|
|
tree_difference = REV_TREE_DIFFERENT;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
|
2006-04-11 03:14:54 +02:00
|
|
|
int rev_compare_tree(struct rev_info *revs, struct tree *t1, struct tree *t2)
|
2006-02-28 20:24:00 +01:00
|
|
|
{
|
|
|
|
if (!t1)
|
2006-03-10 10:21:39 +01:00
|
|
|
return REV_TREE_NEW;
|
2006-02-28 20:24:00 +01:00
|
|
|
if (!t2)
|
2006-03-10 10:21:39 +01:00
|
|
|
return REV_TREE_DIFFERENT;
|
|
|
|
tree_difference = REV_TREE_SAME;
|
2006-04-11 03:14:54 +02:00
|
|
|
if (diff_tree_sha1(t1->object.sha1, t2->object.sha1, "",
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
&revs->pruning) < 0)
|
2006-03-10 10:21:39 +01:00
|
|
|
return REV_TREE_DIFFERENT;
|
2006-02-28 20:24:00 +01:00
|
|
|
return tree_difference;
|
|
|
|
}
|
|
|
|
|
2006-04-11 03:14:54 +02:00
|
|
|
int rev_same_tree_as_empty(struct rev_info *revs, struct tree *t1)
|
2006-02-28 20:24:00 +01:00
|
|
|
{
|
|
|
|
int retval;
|
|
|
|
void *tree;
|
|
|
|
struct tree_desc empty, real;
|
|
|
|
|
|
|
|
if (!t1)
|
|
|
|
return 0;
|
|
|
|
|
2006-04-02 14:44:09 +02:00
|
|
|
tree = read_object_with_reference(t1->object.sha1, tree_type, &real.size, NULL);
|
2006-02-28 20:24:00 +01:00
|
|
|
if (!tree)
|
|
|
|
return 0;
|
|
|
|
real.buf = tree;
|
|
|
|
|
|
|
|
empty.buf = "";
|
|
|
|
empty.size = 0;
|
|
|
|
|
|
|
|
tree_difference = 0;
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
retval = diff_tree(&empty, &real, "", &revs->pruning);
|
2006-02-28 20:24:00 +01:00
|
|
|
free(tree);
|
|
|
|
|
|
|
|
return retval >= 0 && !tree_difference;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
|
|
|
|
{
|
|
|
|
struct commit_list **pp, *parent;
|
2006-03-11 06:59:37 +01:00
|
|
|
int tree_changed = 0;
|
2006-02-28 20:24:00 +01:00
|
|
|
|
|
|
|
if (!commit->tree)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!commit->parents) {
|
2006-04-11 03:14:54 +02:00
|
|
|
if (!rev_same_tree_as_empty(revs, commit->tree))
|
2006-02-28 20:24:00 +01:00
|
|
|
commit->object.flags |= TREECHANGE;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
pp = &commit->parents;
|
|
|
|
while ((parent = *pp) != NULL) {
|
|
|
|
struct commit *p = parent->item;
|
|
|
|
|
|
|
|
parse_commit(p);
|
2006-04-11 03:14:54 +02:00
|
|
|
switch (rev_compare_tree(revs, p->tree, commit->tree)) {
|
2006-03-10 10:21:39 +01:00
|
|
|
case REV_TREE_SAME:
|
2006-06-11 19:57:35 +02:00
|
|
|
if (!revs->simplify_history || (p->object.flags & UNINTERESTING)) {
|
2006-03-11 06:59:37 +01:00
|
|
|
/* Even if a merge with an uninteresting
|
|
|
|
* side branch brought the entire change
|
|
|
|
* we are interested in, we do not want
|
|
|
|
* to lose the other branches of this
|
|
|
|
* merge, so we just keep going.
|
|
|
|
*/
|
|
|
|
pp = &parent->next;
|
|
|
|
continue;
|
|
|
|
}
|
2006-02-28 20:24:00 +01:00
|
|
|
parent->next = NULL;
|
|
|
|
commit->parents = parent;
|
|
|
|
return;
|
|
|
|
|
2006-03-10 10:21:39 +01:00
|
|
|
case REV_TREE_NEW:
|
|
|
|
if (revs->remove_empty_trees &&
|
2006-04-11 03:14:54 +02:00
|
|
|
rev_same_tree_as_empty(revs, p->tree)) {
|
2006-03-12 22:39:31 +01:00
|
|
|
/* We are adding all the specified
|
|
|
|
* paths from this parent, so the
|
|
|
|
* history beyond this parent is not
|
|
|
|
* interesting. Remove its parents
|
|
|
|
* (they are grandparents for us).
|
|
|
|
* IOW, we pretend this parent is a
|
|
|
|
* "root" commit.
|
2006-03-12 22:39:31 +01:00
|
|
|
*/
|
2006-03-12 22:39:31 +01:00
|
|
|
parse_commit(p);
|
|
|
|
p->parents = NULL;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
/* fallthrough */
|
2006-03-10 10:21:39 +01:00
|
|
|
case REV_TREE_DIFFERENT:
|
2006-03-11 06:59:37 +01:00
|
|
|
tree_changed = 1;
|
2006-02-28 20:24:00 +01:00
|
|
|
pp = &parent->next;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
die("bad tree compare for commit %s", sha1_to_hex(commit->object.sha1));
|
|
|
|
}
|
2006-03-11 06:59:37 +01:00
|
|
|
if (tree_changed)
|
|
|
|
commit->object.flags |= TREECHANGE;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void add_parents_to_list(struct rev_info *revs, struct commit *commit, struct commit_list **list)
|
|
|
|
{
|
|
|
|
struct commit_list *parent = commit->parents;
|
|
|
|
|
Make "--parents" logs also be incremental
The parent rewriting feature caused us to create the whole history in one
go, and then simplify it later, because of how rewrite_parents() had been
written. However, with a little tweaking, it's perfectly possible to do
even that one incrementally.
Right now, this doesn't really much matter, because every user of
"--parents" will probably generally _also_ use "--topo-order", which will
cause the old non-incremental behaviour anyway. However, I'm hopeful that
we could make even the topological sort incremental, or at least
_partially_ so (for example, make it incremental up to the first merge).
In the meantime, this at least moves things in the right direction, and
removes a strange special case.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-09 02:05:58 +02:00
|
|
|
if (commit->object.flags & ADDED)
|
|
|
|
return;
|
|
|
|
commit->object.flags |= ADDED;
|
|
|
|
|
2006-02-28 20:24:00 +01:00
|
|
|
/*
|
|
|
|
* If the commit is uninteresting, don't try to
|
|
|
|
* prune parents - we want the maximal uninteresting
|
|
|
|
* set.
|
|
|
|
*
|
|
|
|
* Normally we haven't parsed the parent
|
|
|
|
* yet, so we won't have a parent of a parent
|
|
|
|
* here. However, it may turn out that we've
|
|
|
|
* reached this commit some other way (where it
|
|
|
|
* wasn't uninteresting), in which case we need
|
|
|
|
* to mark its parents recursively too..
|
|
|
|
*/
|
|
|
|
if (commit->object.flags & UNINTERESTING) {
|
|
|
|
while (parent) {
|
|
|
|
struct commit *p = parent->item;
|
|
|
|
parent = parent->next;
|
|
|
|
parse_commit(p);
|
|
|
|
p->object.flags |= UNINTERESTING;
|
|
|
|
if (p->parents)
|
|
|
|
mark_parents_uninteresting(p);
|
|
|
|
if (p->object.flags & SEEN)
|
|
|
|
continue;
|
|
|
|
p->object.flags |= SEEN;
|
|
|
|
insert_by_date(p, list);
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ok, the commit wasn't uninteresting. Try to
|
|
|
|
* simplify the commit history and find the parent
|
|
|
|
* that has no differences in the path set if one exists.
|
|
|
|
*/
|
2006-03-10 10:21:39 +01:00
|
|
|
if (revs->prune_fn)
|
|
|
|
revs->prune_fn(revs, commit);
|
2006-02-28 20:24:00 +01:00
|
|
|
|
2006-04-15 21:09:56 +02:00
|
|
|
if (revs->no_walk)
|
|
|
|
return;
|
|
|
|
|
2006-02-28 20:24:00 +01:00
|
|
|
parent = commit->parents;
|
|
|
|
while (parent) {
|
|
|
|
struct commit *p = parent->item;
|
|
|
|
|
|
|
|
parent = parent->next;
|
|
|
|
|
|
|
|
parse_commit(p);
|
|
|
|
if (p->object.flags & SEEN)
|
|
|
|
continue;
|
|
|
|
p->object.flags |= SEEN;
|
|
|
|
insert_by_date(p, list);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void limit_list(struct rev_info *revs)
|
|
|
|
{
|
|
|
|
struct commit_list *list = revs->commits;
|
|
|
|
struct commit_list *newlist = NULL;
|
|
|
|
struct commit_list **p = &newlist;
|
|
|
|
|
|
|
|
while (list) {
|
|
|
|
struct commit_list *entry = list;
|
|
|
|
struct commit *commit = list->item;
|
|
|
|
struct object *obj = &commit->object;
|
|
|
|
|
|
|
|
list = list->next;
|
|
|
|
free(entry);
|
|
|
|
|
|
|
|
if (revs->max_age != -1 && (commit->date < revs->max_age))
|
|
|
|
obj->flags |= UNINTERESTING;
|
|
|
|
if (revs->unpacked && has_sha1_pack(obj->sha1))
|
|
|
|
obj->flags |= UNINTERESTING;
|
|
|
|
add_parents_to_list(revs, commit, &list);
|
|
|
|
if (obj->flags & UNINTERESTING) {
|
|
|
|
mark_parents_uninteresting(commit);
|
|
|
|
if (everybody_uninteresting(list))
|
|
|
|
break;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (revs->min_age != -1 && (commit->date > revs->min_age))
|
|
|
|
continue;
|
|
|
|
p = &commit_list_insert(commit, p)->next;
|
|
|
|
}
|
2006-03-28 09:58:34 +02:00
|
|
|
if (revs->boundary) {
|
2006-03-31 09:59:19 +02:00
|
|
|
/* mark the ones that are on the result list first */
|
|
|
|
for (list = newlist; list; list = list->next) {
|
|
|
|
struct commit *commit = list->item;
|
|
|
|
commit->object.flags |= TMP_MARK;
|
|
|
|
}
|
|
|
|
for (list = newlist; list; list = list->next) {
|
2006-03-28 09:58:34 +02:00
|
|
|
struct commit *commit = list->item;
|
|
|
|
struct object *obj = &commit->object;
|
2006-03-31 09:59:19 +02:00
|
|
|
struct commit_list *parent;
|
|
|
|
if (obj->flags & UNINTERESTING)
|
2006-03-28 09:58:34 +02:00
|
|
|
continue;
|
2006-03-31 09:59:19 +02:00
|
|
|
for (parent = commit->parents;
|
|
|
|
parent;
|
|
|
|
parent = parent->next) {
|
2006-03-28 09:58:34 +02:00
|
|
|
struct commit *pcommit = parent->item;
|
|
|
|
if (!(pcommit->object.flags & UNINTERESTING))
|
|
|
|
continue;
|
|
|
|
pcommit->object.flags |= BOUNDARY;
|
2006-03-31 09:59:19 +02:00
|
|
|
if (pcommit->object.flags & TMP_MARK)
|
|
|
|
continue;
|
|
|
|
pcommit->object.flags |= TMP_MARK;
|
2006-03-28 09:58:34 +02:00
|
|
|
p = &commit_list_insert(pcommit, p)->next;
|
|
|
|
}
|
2006-03-31 09:59:19 +02:00
|
|
|
}
|
|
|
|
for (list = newlist; list; list = list->next) {
|
|
|
|
struct commit *commit = list->item;
|
|
|
|
commit->object.flags &= ~TMP_MARK;
|
2006-03-28 09:58:34 +02:00
|
|
|
}
|
|
|
|
}
|
2006-02-28 20:24:00 +01:00
|
|
|
revs->commits = newlist;
|
|
|
|
}
|
|
|
|
|
2006-02-26 01:19:46 +01:00
|
|
|
static int all_flags;
|
|
|
|
static struct rev_info *all_revs;
|
|
|
|
|
|
|
|
static int handle_one_ref(const char *path, const unsigned char *sha1)
|
|
|
|
{
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
struct object *object = get_reference(all_revs, path, sha1, all_flags);
|
|
|
|
add_pending_object(all_revs, object, "");
|
2006-02-26 01:19:46 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void handle_all(struct rev_info *revs, unsigned flags)
|
|
|
|
{
|
|
|
|
all_revs = revs;
|
|
|
|
all_flags = flags;
|
|
|
|
for_each_ref(handle_one_ref);
|
|
|
|
}
|
|
|
|
|
2006-04-30 09:54:29 +02:00
|
|
|
static int add_parents_only(struct rev_info *revs, const char *arg, int flags)
|
|
|
|
{
|
|
|
|
unsigned char sha1[20];
|
|
|
|
struct object *it;
|
|
|
|
struct commit *commit;
|
|
|
|
struct commit_list *parents;
|
|
|
|
|
|
|
|
if (*arg == '^') {
|
|
|
|
flags ^= UNINTERESTING;
|
|
|
|
arg++;
|
|
|
|
}
|
|
|
|
if (get_sha1(arg, sha1))
|
|
|
|
return 0;
|
|
|
|
while (1) {
|
|
|
|
it = get_reference(revs, arg, sha1, 0);
|
Shrink "struct object" a bit
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-15 01:45:13 +02:00
|
|
|
if (it->type != TYPE_TAG)
|
2006-04-30 09:54:29 +02:00
|
|
|
break;
|
|
|
|
memcpy(sha1, ((struct tag*)it)->tagged->sha1, 20);
|
|
|
|
}
|
Shrink "struct object" a bit
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-15 01:45:13 +02:00
|
|
|
if (it->type != TYPE_COMMIT)
|
2006-04-30 09:54:29 +02:00
|
|
|
return 0;
|
|
|
|
commit = (struct commit *)it;
|
|
|
|
for (parents = commit->parents; parents; parents = parents->next) {
|
|
|
|
it = &parents->item->object;
|
|
|
|
it->flags |= flags;
|
|
|
|
add_pending_object(revs, it, arg);
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2006-03-10 10:21:39 +01:00
|
|
|
void init_revisions(struct rev_info *revs)
|
|
|
|
{
|
|
|
|
memset(revs, 0, sizeof(*revs));
|
2006-04-15 07:19:38 +02:00
|
|
|
|
2006-04-16 08:46:36 +02:00
|
|
|
revs->abbrev = DEFAULT_ABBREV;
|
2006-04-15 07:19:38 +02:00
|
|
|
revs->ignore_merges = 1;
|
2006-06-11 19:57:35 +02:00
|
|
|
revs->simplify_history = 1;
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
revs->pruning.recursive = 1;
|
|
|
|
revs->pruning.add_remove = file_add_remove;
|
|
|
|
revs->pruning.change = file_change;
|
2006-03-10 10:21:39 +01:00
|
|
|
revs->lifo = 1;
|
|
|
|
revs->dense = 1;
|
|
|
|
revs->prefix = setup_git_directory();
|
|
|
|
revs->max_age = -1;
|
|
|
|
revs->min_age = -1;
|
|
|
|
revs->max_count = -1;
|
|
|
|
|
|
|
|
revs->prune_fn = NULL;
|
|
|
|
revs->prune_data = NULL;
|
|
|
|
|
|
|
|
revs->topo_setter = topo_sort_default_setter;
|
|
|
|
revs->topo_getter = topo_sort_default_getter;
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
|
|
|
|
revs->commit_format = CMIT_FMT_DEFAULT;
|
|
|
|
|
|
|
|
diff_setup(&revs->diffopt);
|
2006-03-10 10:21:39 +01:00
|
|
|
}
|
|
|
|
|
2006-02-26 01:19:46 +01:00
|
|
|
/*
|
|
|
|
* Parse revision information, filling in the "rev_info" structure,
|
|
|
|
* and removing the used arguments from the argument list.
|
|
|
|
*
|
2006-03-01 00:07:20 +01:00
|
|
|
* Returns the number of arguments left that weren't recognized
|
|
|
|
* (which are also moved to the head of the argument list)
|
2006-02-26 01:19:46 +01:00
|
|
|
*/
|
2006-02-28 20:24:00 +01:00
|
|
|
int setup_revisions(int argc, const char **argv, struct rev_info *revs, const char *def)
|
2006-02-26 01:19:46 +01:00
|
|
|
{
|
|
|
|
int i, flags, seen_dashdash;
|
2006-03-01 00:07:20 +01:00
|
|
|
const char **unrecognized = argv + 1;
|
2006-02-26 01:19:46 +01:00
|
|
|
int left = 1;
|
|
|
|
|
|
|
|
/* First, search for "--" */
|
|
|
|
seen_dashdash = 0;
|
|
|
|
for (i = 1; i < argc; i++) {
|
|
|
|
const char *arg = argv[i];
|
|
|
|
if (strcmp(arg, "--"))
|
|
|
|
continue;
|
|
|
|
argv[i] = NULL;
|
|
|
|
argc = i;
|
2006-03-10 10:21:39 +01:00
|
|
|
revs->prune_data = get_pathspec(revs->prefix, argv + i + 1);
|
2006-02-26 01:19:46 +01:00
|
|
|
seen_dashdash = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
flags = 0;
|
|
|
|
for (i = 1; i < argc; i++) {
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
struct object *object;
|
2006-02-26 01:19:46 +01:00
|
|
|
const char *arg = argv[i];
|
|
|
|
unsigned char sha1[20];
|
|
|
|
char *dotdot;
|
|
|
|
int local_flags;
|
|
|
|
|
|
|
|
if (*arg == '-') {
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
int opts;
|
2006-02-26 01:19:46 +01:00
|
|
|
if (!strncmp(arg, "--max-count=", 12)) {
|
|
|
|
revs->max_count = atoi(arg + 12);
|
|
|
|
continue;
|
|
|
|
}
|
2006-05-03 12:51:40 +02:00
|
|
|
/* accept -<digit>, like traditional "head" */
|
2006-03-03 00:24:01 +01:00
|
|
|
if ((*arg == '-') && isdigit(arg[1])) {
|
|
|
|
revs->max_count = atoi(arg + 1);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-n")) {
|
|
|
|
if (argc <= i + 1)
|
|
|
|
die("-n requires an argument");
|
|
|
|
revs->max_count = atoi(argv[++i]);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg,"-n",2)) {
|
|
|
|
revs->max_count = atoi(arg + 2);
|
|
|
|
continue;
|
|
|
|
}
|
2006-02-26 01:19:46 +01:00
|
|
|
if (!strncmp(arg, "--max-age=", 10)) {
|
|
|
|
revs->max_age = atoi(arg + 10);
|
|
|
|
continue;
|
|
|
|
}
|
2006-03-01 09:12:37 +01:00
|
|
|
if (!strncmp(arg, "--since=", 8)) {
|
|
|
|
revs->max_age = approxidate(arg + 8);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg, "--after=", 8)) {
|
|
|
|
revs->max_age = approxidate(arg + 8);
|
2006-04-02 04:38:25 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg, "--min-age=", 10)) {
|
|
|
|
revs->min_age = atoi(arg + 10);
|
2006-03-01 09:12:37 +01:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg, "--before=", 9)) {
|
|
|
|
revs->min_age = approxidate(arg + 9);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg, "--until=", 8)) {
|
|
|
|
revs->min_age = approxidate(arg + 8);
|
|
|
|
continue;
|
|
|
|
}
|
2006-02-26 01:19:46 +01:00
|
|
|
if (!strcmp(arg, "--all")) {
|
|
|
|
handle_all(revs, flags);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--not")) {
|
|
|
|
flags ^= UNINTERESTING;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--default")) {
|
|
|
|
if (++i >= argc)
|
|
|
|
die("bad --default argument");
|
|
|
|
def = argv[i];
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--topo-order")) {
|
|
|
|
revs->topo_order = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--date-order")) {
|
|
|
|
revs->lifo = 0;
|
|
|
|
revs->topo_order = 1;
|
|
|
|
continue;
|
|
|
|
}
|
2006-03-31 02:52:42 +02:00
|
|
|
if (!strcmp(arg, "--parents")) {
|
|
|
|
revs->parents = 1;
|
|
|
|
continue;
|
|
|
|
}
|
2006-02-26 01:19:46 +01:00
|
|
|
if (!strcmp(arg, "--dense")) {
|
|
|
|
revs->dense = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--sparse")) {
|
|
|
|
revs->dense = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--remove-empty")) {
|
|
|
|
revs->remove_empty_trees = 1;
|
|
|
|
continue;
|
|
|
|
}
|
2006-03-28 10:04:50 +02:00
|
|
|
if (!strcmp(arg, "--no-merges")) {
|
2006-03-01 00:07:20 +01:00
|
|
|
revs->no_merges = 1;
|
|
|
|
continue;
|
|
|
|
}
|
2006-03-28 09:58:34 +02:00
|
|
|
if (!strcmp(arg, "--boundary")) {
|
|
|
|
revs->boundary = 1;
|
|
|
|
continue;
|
|
|
|
}
|
2006-02-26 01:19:46 +01:00
|
|
|
if (!strcmp(arg, "--objects")) {
|
|
|
|
revs->tag_objects = 1;
|
|
|
|
revs->tree_objects = 1;
|
|
|
|
revs->blob_objects = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--objects-edge")) {
|
|
|
|
revs->tag_objects = 1;
|
|
|
|
revs->tree_objects = 1;
|
|
|
|
revs->blob_objects = 1;
|
|
|
|
revs->edge_hint = 1;
|
|
|
|
continue;
|
|
|
|
}
|
2006-02-27 17:54:36 +01:00
|
|
|
if (!strcmp(arg, "--unpacked")) {
|
|
|
|
revs->unpacked = 1;
|
|
|
|
continue;
|
|
|
|
}
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
if (!strcmp(arg, "-r")) {
|
|
|
|
revs->diff = 1;
|
|
|
|
revs->diffopt.recursive = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-t")) {
|
|
|
|
revs->diff = 1;
|
|
|
|
revs->diffopt.recursive = 1;
|
|
|
|
revs->diffopt.tree_in_recursive = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-m")) {
|
|
|
|
revs->ignore_merges = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-c")) {
|
|
|
|
revs->diff = 1;
|
2006-04-29 10:24:49 +02:00
|
|
|
revs->dense_combined_merges = 0;
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
revs->combine_merges = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--cc")) {
|
|
|
|
revs->diff = 1;
|
|
|
|
revs->dense_combined_merges = 1;
|
|
|
|
revs->combine_merges = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "-v")) {
|
|
|
|
revs->verbose_header = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strncmp(arg, "--pretty", 8)) {
|
|
|
|
revs->verbose_header = 1;
|
|
|
|
revs->commit_format = get_commit_format(arg+8);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--root")) {
|
|
|
|
revs->show_root_diff = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--no-commit-id")) {
|
|
|
|
revs->no_commit_id = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--always")) {
|
|
|
|
revs->always_show_header = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--no-abbrev")) {
|
|
|
|
revs->abbrev = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--abbrev")) {
|
|
|
|
revs->abbrev = DEFAULT_ABBREV;
|
|
|
|
continue;
|
|
|
|
}
|
2006-05-27 21:24:30 +02:00
|
|
|
if (!strncmp(arg, "--abbrev=", 9)) {
|
|
|
|
revs->abbrev = strtoul(arg + 9, NULL, 10);
|
|
|
|
if (revs->abbrev < MINIMUM_ABBREV)
|
|
|
|
revs->abbrev = MINIMUM_ABBREV;
|
|
|
|
else if (revs->abbrev > 40)
|
|
|
|
revs->abbrev = 40;
|
|
|
|
continue;
|
|
|
|
}
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
if (!strcmp(arg, "--abbrev-commit")) {
|
|
|
|
revs->abbrev_commit = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--full-diff")) {
|
|
|
|
revs->diff = 1;
|
|
|
|
revs->full_diff = 1;
|
|
|
|
continue;
|
|
|
|
}
|
2006-06-11 19:57:35 +02:00
|
|
|
if (!strcmp(arg, "--full-history")) {
|
|
|
|
revs->simplify_history = 0;
|
|
|
|
continue;
|
|
|
|
}
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
opts = diff_opt_parse(&revs->diffopt, argv+i, argc-i);
|
|
|
|
if (opts > 0) {
|
|
|
|
revs->diff = 1;
|
|
|
|
i += opts - 1;
|
|
|
|
continue;
|
|
|
|
}
|
2006-02-26 01:19:46 +01:00
|
|
|
*unrecognized++ = arg;
|
|
|
|
left++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
dotdot = strstr(arg, "..");
|
|
|
|
if (dotdot) {
|
|
|
|
unsigned char from_sha1[20];
|
2006-03-30 09:30:52 +02:00
|
|
|
const char *next = dotdot + 2;
|
|
|
|
const char *this = arg;
|
2006-02-26 01:19:46 +01:00
|
|
|
*dotdot = 0;
|
|
|
|
if (!*next)
|
2006-03-30 09:30:52 +02:00
|
|
|
next = "HEAD";
|
2006-03-30 05:41:37 +02:00
|
|
|
if (dotdot == arg)
|
2006-03-30 09:30:52 +02:00
|
|
|
this = "HEAD";
|
2006-03-30 05:41:37 +02:00
|
|
|
if (!get_sha1(this, from_sha1) &&
|
|
|
|
!get_sha1(next, sha1)) {
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
struct object *exclude;
|
|
|
|
struct object *include;
|
2006-02-26 01:19:46 +01:00
|
|
|
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
exclude = get_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
|
|
|
|
include = get_reference(revs, next, sha1, flags);
|
2006-02-26 01:19:46 +01:00
|
|
|
if (!exclude || !include)
|
|
|
|
die("Invalid revision range %s..%s", arg, next);
|
2006-04-27 00:09:27 +02:00
|
|
|
|
|
|
|
if (!seen_dashdash) {
|
|
|
|
*dotdot = '.';
|
|
|
|
verify_non_filename(revs->prefix, arg);
|
|
|
|
}
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
add_pending_object(revs, exclude, this);
|
|
|
|
add_pending_object(revs, include, next);
|
2006-02-26 01:19:46 +01:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
*dotdot = '.';
|
|
|
|
}
|
2006-04-30 09:54:29 +02:00
|
|
|
dotdot = strstr(arg, "^@");
|
|
|
|
if (dotdot && !dotdot[2]) {
|
|
|
|
*dotdot = 0;
|
|
|
|
if (add_parents_only(revs, arg, flags))
|
|
|
|
continue;
|
|
|
|
*dotdot = '^';
|
|
|
|
}
|
2006-02-26 01:19:46 +01:00
|
|
|
local_flags = 0;
|
|
|
|
if (*arg == '^') {
|
|
|
|
local_flags = UNINTERESTING;
|
|
|
|
arg++;
|
|
|
|
}
|
2006-05-08 23:43:38 +02:00
|
|
|
if (get_sha1(arg, sha1)) {
|
2006-02-26 01:19:46 +01:00
|
|
|
int j;
|
|
|
|
|
|
|
|
if (seen_dashdash || local_flags)
|
|
|
|
die("bad revision '%s'", arg);
|
|
|
|
|
2006-04-27 00:09:27 +02:00
|
|
|
/* If we didn't have a "--":
|
|
|
|
* (1) all filenames must exist;
|
|
|
|
* (2) all rev-args must not be interpretable
|
|
|
|
* as a valid filename.
|
|
|
|
* but the latter we have checked in the main loop.
|
|
|
|
*/
|
2006-04-26 19:15:54 +02:00
|
|
|
for (j = i; j < argc; j++)
|
|
|
|
verify_filename(revs->prefix, argv[j]);
|
|
|
|
|
2006-03-10 10:21:39 +01:00
|
|
|
revs->prune_data = get_pathspec(revs->prefix, argv + i);
|
2006-02-26 01:19:46 +01:00
|
|
|
break;
|
|
|
|
}
|
2006-04-27 00:09:27 +02:00
|
|
|
if (!seen_dashdash)
|
|
|
|
verify_non_filename(revs->prefix, arg);
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
object = get_reference(revs, arg, sha1, flags ^ local_flags);
|
|
|
|
add_pending_object(revs, object, arg);
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
Add "named object array" concept
We've had this notion of a "object_list" for a long time, which eventually
grew a "name" member because some users (notably git-rev-list) wanted to
name each object as it is generated.
That object_list is great for some things, but it isn't all that wonderful
for others, and the "name" member is generally not used by everybody.
This patch splits the users of the object_list array up into two: the
traditional list users, who want the list-like format, and who don't
actually use or want the name. And another class of users that really used
the list as an extensible array, and generally wanted to name the objects.
The patch is fairly straightforward, but it's also biggish. Most of it
really just cleans things up: switching the revision parsing and listing
over to the array makes things like the builtin-diff usage much simpler
(we now see exactly how many members the array has, and we don't get the
objects reversed from the order they were on the command line).
One of the main reasons for doing this at all is that the malloc overhead
of the simple object list was actually pretty high, and the array is just
a lot denser. So this patch brings down memory usage by git-rev-list by
just under 3% (on top of all the other memory use optimizations) on the
mozilla archive.
It does add more lines than it removes, and more importantly, it adds a
whole new infrastructure for maintaining lists of objects, but on the
other hand, the new dynamic array code is pretty obvious. The change to
builtin-diff-tree.c shows a fairly good example of why an array interface
is sometimes more natural, and just much simpler for everybody.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-20 02:42:35 +02:00
|
|
|
if (def && !revs->pending.nr) {
|
2006-02-26 01:19:46 +01:00
|
|
|
unsigned char sha1[20];
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
struct object *object;
|
2006-05-08 23:43:38 +02:00
|
|
|
if (get_sha1(def, sha1))
|
2006-02-26 01:19:46 +01:00
|
|
|
die("bad default revision '%s'", def);
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
object = get_reference(revs, def, sha1, 0);
|
|
|
|
add_pending_object(revs, object, def);
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
2006-03-10 10:21:39 +01:00
|
|
|
|
2006-04-02 05:13:22 +02:00
|
|
|
if (revs->topo_order || revs->unpacked)
|
2006-04-02 04:38:25 +02:00
|
|
|
revs->limited = 1;
|
|
|
|
|
2006-03-10 10:21:39 +01:00
|
|
|
if (revs->prune_data) {
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
diff_tree_setup_paths(revs->prune_data, &revs->pruning);
|
2006-03-10 10:21:39 +01:00
|
|
|
revs->prune_fn = try_to_simplify_commit;
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
if (!revs->full_diff)
|
|
|
|
diff_tree_setup_paths(revs->prune_data, &revs->diffopt);
|
2006-03-10 10:21:39 +01:00
|
|
|
}
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
if (revs->combine_merges) {
|
|
|
|
revs->ignore_merges = 0;
|
2006-04-22 04:39:04 +02:00
|
|
|
if (revs->dense_combined_merges &&
|
|
|
|
(revs->diffopt.output_format != DIFF_FORMAT_DIFFSTAT))
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
revs->diffopt.output_format = DIFF_FORMAT_PATCH;
|
|
|
|
}
|
|
|
|
revs->diffopt.abbrev = revs->abbrev;
|
|
|
|
diff_setup_done(&revs->diffopt);
|
2006-03-10 10:21:39 +01:00
|
|
|
|
2006-02-26 01:19:46 +01:00
|
|
|
return left;
|
|
|
|
}
|
2006-02-28 20:24:00 +01:00
|
|
|
|
|
|
|
void prepare_revision_walk(struct rev_info *revs)
|
|
|
|
{
|
Add "named object array" concept
We've had this notion of a "object_list" for a long time, which eventually
grew a "name" member because some users (notably git-rev-list) wanted to
name each object as it is generated.
That object_list is great for some things, but it isn't all that wonderful
for others, and the "name" member is generally not used by everybody.
This patch splits the users of the object_list array up into two: the
traditional list users, who want the list-like format, and who don't
actually use or want the name. And another class of users that really used
the list as an extensible array, and generally wanted to name the objects.
The patch is fairly straightforward, but it's also biggish. Most of it
really just cleans things up: switching the revision parsing and listing
over to the array makes things like the builtin-diff usage much simpler
(we now see exactly how many members the array has, and we don't get the
objects reversed from the order they were on the command line).
One of the main reasons for doing this at all is that the malloc overhead
of the simple object list was actually pretty high, and the array is just
a lot denser. So this patch brings down memory usage by git-rev-list by
just under 3% (on top of all the other memory use optimizations) on the
mozilla archive.
It does add more lines than it removes, and more importantly, it adds a
whole new infrastructure for maintaining lists of objects, but on the
other hand, the new dynamic array code is pretty obvious. The change to
builtin-diff-tree.c shows a fairly good example of why an array interface
is sometimes more natural, and just much simpler for everybody.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-20 02:42:35 +02:00
|
|
|
int nr = revs->pending.nr;
|
|
|
|
struct object_array_entry *list = revs->pending.objects;
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
|
Add "named object array" concept
We've had this notion of a "object_list" for a long time, which eventually
grew a "name" member because some users (notably git-rev-list) wanted to
name each object as it is generated.
That object_list is great for some things, but it isn't all that wonderful
for others, and the "name" member is generally not used by everybody.
This patch splits the users of the object_list array up into two: the
traditional list users, who want the list-like format, and who don't
actually use or want the name. And another class of users that really used
the list as an extensible array, and generally wanted to name the objects.
The patch is fairly straightforward, but it's also biggish. Most of it
really just cleans things up: switching the revision parsing and listing
over to the array makes things like the builtin-diff usage much simpler
(we now see exactly how many members the array has, and we don't get the
objects reversed from the order they were on the command line).
One of the main reasons for doing this at all is that the malloc overhead
of the simple object list was actually pretty high, and the array is just
a lot denser. So this patch brings down memory usage by git-rev-list by
just under 3% (on top of all the other memory use optimizations) on the
mozilla archive.
It does add more lines than it removes, and more importantly, it adds a
whole new infrastructure for maintaining lists of objects, but on the
other hand, the new dynamic array code is pretty obvious. The change to
builtin-diff-tree.c shows a fairly good example of why an array interface
is sometimes more natural, and just much simpler for everybody.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-20 02:42:35 +02:00
|
|
|
revs->pending.nr = 0;
|
|
|
|
revs->pending.alloc = 0;
|
|
|
|
revs->pending.objects = NULL;
|
|
|
|
while (--nr >= 0) {
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
struct commit *commit = handle_commit(revs, list->item, list->name);
|
|
|
|
if (commit) {
|
|
|
|
if (!(commit->object.flags & SEEN)) {
|
|
|
|
commit->object.flags |= SEEN;
|
|
|
|
insert_by_date(commit, &revs->commits);
|
|
|
|
}
|
|
|
|
}
|
Add "named object array" concept
We've had this notion of a "object_list" for a long time, which eventually
grew a "name" member because some users (notably git-rev-list) wanted to
name each object as it is generated.
That object_list is great for some things, but it isn't all that wonderful
for others, and the "name" member is generally not used by everybody.
This patch splits the users of the object_list array up into two: the
traditional list users, who want the list-like format, and who don't
actually use or want the name. And another class of users that really used
the list as an extensible array, and generally wanted to name the objects.
The patch is fairly straightforward, but it's also biggish. Most of it
really just cleans things up: switching the revision parsing and listing
over to the array makes things like the builtin-diff usage much simpler
(we now see exactly how many members the array has, and we don't get the
objects reversed from the order they were on the command line).
One of the main reasons for doing this at all is that the malloc overhead
of the simple object list was actually pretty high, and the array is just
a lot denser. So this patch brings down memory usage by git-rev-list by
just under 3% (on top of all the other memory use optimizations) on the
mozilla archive.
It does add more lines than it removes, and more importantly, it adds a
whole new infrastructure for maintaining lists of objects, but on the
other hand, the new dynamic array code is pretty obvious. The change to
builtin-diff-tree.c shows a fairly good example of why an array interface
is sometimes more natural, and just much simpler for everybody.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-20 02:42:35 +02:00
|
|
|
list++;
|
Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out
- get rid of "struct log_tree_opt"
The fields in "log_tree_opt" are moved into "struct rev_info", and all
users of log_tree_opt are changed to use the rev_info struct instead.
- add the parsing for the log_tree_opt arguments to "setup_revision()"
- make setup_revision set a flag (revs->diff) if the diff-related
arguments were used. This allows "git log" to decide whether it wants
to show diffs or not.
- make setup_revision() also initialize the diffopt part of rev_info
(which we had from before, but we just didn't initialize it)
- make setup_revision() do all the "finishing touches" on it all (it will
do the proper flag combination logic, and call "diff_setup_done()")
Now, that was the easy and straightforward part.
The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.
Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.
This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.
However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.
Even in this form, it actually ends up removing more lines than it adds.
It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.
I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.
[jc: squashed the original and three "oops this too" updates, with
another fix-up.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-15 01:52:13 +02:00
|
|
|
}
|
|
|
|
|
2006-04-15 21:09:56 +02:00
|
|
|
if (revs->no_walk)
|
|
|
|
return;
|
2006-02-28 20:24:00 +01:00
|
|
|
if (revs->limited)
|
|
|
|
limit_list(revs);
|
|
|
|
if (revs->topo_order)
|
2006-03-10 10:21:39 +01:00
|
|
|
sort_in_topological_order_fn(&revs->commits, revs->lifo,
|
|
|
|
revs->topo_setter,
|
|
|
|
revs->topo_getter);
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
|
Make "--parents" logs also be incremental
The parent rewriting feature caused us to create the whole history in one
go, and then simplify it later, because of how rewrite_parents() had been
written. However, with a little tweaking, it's perfectly possible to do
even that one incrementally.
Right now, this doesn't really much matter, because every user of
"--parents" will probably generally _also_ use "--topo-order", which will
cause the old non-incremental behaviour anyway. However, I'm hopeful that
we could make even the topological sort incremental, or at least
_partially_ so (for example, make it incremental up to the first merge).
In the meantime, this at least moves things in the right direction, and
removes a strange special case.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-09 02:05:58 +02:00
|
|
|
static int rewrite_one(struct rev_info *revs, struct commit **pp)
|
2006-03-01 00:07:20 +01:00
|
|
|
{
|
|
|
|
for (;;) {
|
|
|
|
struct commit *p = *pp;
|
Make "--parents" logs also be incremental
The parent rewriting feature caused us to create the whole history in one
go, and then simplify it later, because of how rewrite_parents() had been
written. However, with a little tweaking, it's perfectly possible to do
even that one incrementally.
Right now, this doesn't really much matter, because every user of
"--parents" will probably generally _also_ use "--topo-order", which will
cause the old non-incremental behaviour anyway. However, I'm hopeful that
we could make even the topological sort incremental, or at least
_partially_ so (for example, make it incremental up to the first merge).
In the meantime, this at least moves things in the right direction, and
removes a strange special case.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-09 02:05:58 +02:00
|
|
|
if (!revs->limited)
|
|
|
|
add_parents_to_list(revs, p, &revs->commits);
|
2006-03-01 00:07:20 +01:00
|
|
|
if (p->object.flags & (TREECHANGE | UNINTERESTING))
|
|
|
|
return 0;
|
|
|
|
if (!p->parents)
|
|
|
|
return -1;
|
|
|
|
*pp = p->parents->item;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Make "--parents" logs also be incremental
The parent rewriting feature caused us to create the whole history in one
go, and then simplify it later, because of how rewrite_parents() had been
written. However, with a little tweaking, it's perfectly possible to do
even that one incrementally.
Right now, this doesn't really much matter, because every user of
"--parents" will probably generally _also_ use "--topo-order", which will
cause the old non-incremental behaviour anyway. However, I'm hopeful that
we could make even the topological sort incremental, or at least
_partially_ so (for example, make it incremental up to the first merge).
In the meantime, this at least moves things in the right direction, and
removes a strange special case.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-09 02:05:58 +02:00
|
|
|
static void rewrite_parents(struct rev_info *revs, struct commit *commit)
|
2006-03-01 00:07:20 +01:00
|
|
|
{
|
|
|
|
struct commit_list **pp = &commit->parents;
|
|
|
|
while (*pp) {
|
|
|
|
struct commit_list *parent = *pp;
|
Make "--parents" logs also be incremental
The parent rewriting feature caused us to create the whole history in one
go, and then simplify it later, because of how rewrite_parents() had been
written. However, with a little tweaking, it's perfectly possible to do
even that one incrementally.
Right now, this doesn't really much matter, because every user of
"--parents" will probably generally _also_ use "--topo-order", which will
cause the old non-incremental behaviour anyway. However, I'm hopeful that
we could make even the topological sort incremental, or at least
_partially_ so (for example, make it incremental up to the first merge).
In the meantime, this at least moves things in the right direction, and
removes a strange special case.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-09 02:05:58 +02:00
|
|
|
if (rewrite_one(revs, &parent->item) < 0) {
|
2006-03-01 00:07:20 +01:00
|
|
|
*pp = parent->next;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
pp = &parent->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-04-17 03:12:49 +02:00
|
|
|
static void mark_boundary_to_show(struct commit *commit)
|
|
|
|
{
|
|
|
|
struct commit_list *p = commit->parents;
|
|
|
|
while (p) {
|
|
|
|
commit = p->item;
|
|
|
|
p = p->next;
|
|
|
|
if (commit->object.flags & BOUNDARY)
|
|
|
|
commit->object.flags |= BOUNDARY_SHOW;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-02-28 20:24:00 +01:00
|
|
|
struct commit *get_revision(struct rev_info *revs)
|
|
|
|
{
|
2006-03-01 00:07:20 +01:00
|
|
|
struct commit_list *list = revs->commits;
|
|
|
|
|
|
|
|
if (!list)
|
2006-02-28 20:24:00 +01:00
|
|
|
return NULL;
|
|
|
|
|
2006-03-01 00:07:20 +01:00
|
|
|
/* Check the max_count ... */
|
|
|
|
switch (revs->max_count) {
|
|
|
|
case -1:
|
|
|
|
break;
|
|
|
|
case 0:
|
|
|
|
return NULL;
|
|
|
|
default:
|
|
|
|
revs->max_count--;
|
|
|
|
}
|
2006-02-28 20:24:00 +01:00
|
|
|
|
2006-03-01 00:07:20 +01:00
|
|
|
do {
|
2006-06-18 03:47:58 +02:00
|
|
|
struct commit_list *entry = revs->commits;
|
|
|
|
struct commit *commit = entry->item;
|
2006-03-05 18:53:52 +01:00
|
|
|
|
2006-06-18 03:47:58 +02:00
|
|
|
revs->commits = entry->next;
|
|
|
|
free(entry);
|
Make path-limiting be incremental when possible.
This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.
This makes things like "git log -- pathname" much more pleasant to use.
This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.
What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".
This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.
The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing
git-rev-list HEAD -- drivers/char/ | md5sum
before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.
Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing
git log drivers/
on the kernel archive, or even better, on the _historic_ kernel archive.
With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.
NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.
MAYBE we can fix that too at some point, but I won't promise anything.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-31 03:05:25 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we haven't done the list limiting, we need to look at
|
2006-04-02 02:35:06 +02:00
|
|
|
* the parents here. We also need to do the date-based limiting
|
|
|
|
* that we'd otherwise have done in limit_list().
|
Make path-limiting be incremental when possible.
This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.
This makes things like "git log -- pathname" much more pleasant to use.
This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.
What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".
This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.
The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing
git-rev-list HEAD -- drivers/char/ | md5sum
before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.
Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing
git log drivers/
on the kernel archive, or even better, on the _historic_ kernel archive.
With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.
NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.
MAYBE we can fix that too at some point, but I won't promise anything.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-31 03:05:25 +02:00
|
|
|
*/
|
2006-04-02 02:35:06 +02:00
|
|
|
if (!revs->limited) {
|
2006-04-02 04:52:58 +02:00
|
|
|
if ((revs->unpacked &&
|
|
|
|
has_sha1_pack(commit->object.sha1)) ||
|
|
|
|
(revs->max_age != -1 &&
|
|
|
|
(commit->date < revs->max_age)))
|
2006-04-02 02:35:06 +02:00
|
|
|
continue;
|
Make path-limiting be incremental when possible.
This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.
This makes things like "git log -- pathname" much more pleasant to use.
This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.
What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".
This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.
The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing
git-rev-list HEAD -- drivers/char/ | md5sum
before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.
Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing
git log drivers/
on the kernel archive, or even better, on the _historic_ kernel archive.
With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.
NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.
MAYBE we can fix that too at some point, but I won't promise anything.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-31 03:05:25 +02:00
|
|
|
add_parents_to_list(revs, commit, &revs->commits);
|
2006-04-02 02:35:06 +02:00
|
|
|
}
|
2006-03-28 09:58:34 +02:00
|
|
|
if (commit->object.flags & SHOWN)
|
Make path-limiting be incremental when possible.
This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.
This makes things like "git log -- pathname" much more pleasant to use.
This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.
What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".
This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.
The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing
git-rev-list HEAD -- drivers/char/ | md5sum
before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.
Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing
git log drivers/
on the kernel archive, or even better, on the _historic_ kernel archive.
With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.
NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.
MAYBE we can fix that too at some point, but I won't promise anything.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-31 03:05:25 +02:00
|
|
|
continue;
|
2006-04-17 03:12:49 +02:00
|
|
|
|
|
|
|
/* We want to show boundary commits only when their
|
|
|
|
* children are shown. When path-limiter is in effect,
|
|
|
|
* rewrite_parents() drops some commits from getting shown,
|
|
|
|
* and there is no point showing boundary parents that
|
|
|
|
* are not shown. After rewrite_parents() rewrites the
|
|
|
|
* parents of a commit that is shown, we mark the boundary
|
|
|
|
* parents with BOUNDARY_SHOW.
|
|
|
|
*/
|
|
|
|
if (commit->object.flags & BOUNDARY_SHOW) {
|
|
|
|
commit->object.flags |= SHOWN;
|
|
|
|
return commit;
|
|
|
|
}
|
|
|
|
if (commit->object.flags & UNINTERESTING)
|
Make path-limiting be incremental when possible.
This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.
This makes things like "git log -- pathname" much more pleasant to use.
This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.
What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".
This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.
The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing
git-rev-list HEAD -- drivers/char/ | md5sum
before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.
Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing
git log drivers/
on the kernel archive, or even better, on the _historic_ kernel archive.
With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.
NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.
MAYBE we can fix that too at some point, but I won't promise anything.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-31 03:05:25 +02:00
|
|
|
continue;
|
2006-03-01 00:07:20 +01:00
|
|
|
if (revs->min_age != -1 && (commit->date > revs->min_age))
|
Make path-limiting be incremental when possible.
This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.
This makes things like "git log -- pathname" much more pleasant to use.
This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.
What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".
This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.
The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing
git-rev-list HEAD -- drivers/char/ | md5sum
before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.
Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing
git log drivers/
on the kernel archive, or even better, on the _historic_ kernel archive.
With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.
NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.
MAYBE we can fix that too at some point, but I won't promise anything.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-31 03:05:25 +02:00
|
|
|
continue;
|
2006-03-28 09:58:34 +02:00
|
|
|
if (revs->no_merges &&
|
|
|
|
commit->parents && commit->parents->next)
|
Make path-limiting be incremental when possible.
This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.
This makes things like "git log -- pathname" much more pleasant to use.
This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.
What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".
This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.
The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing
git-rev-list HEAD -- drivers/char/ | md5sum
before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.
Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing
git log drivers/
on the kernel archive, or even better, on the _historic_ kernel archive.
With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.
NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.
MAYBE we can fix that too at some point, but I won't promise anything.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-31 03:05:25 +02:00
|
|
|
continue;
|
2006-03-10 10:21:39 +01:00
|
|
|
if (revs->prune_fn && revs->dense) {
|
2006-03-01 00:07:20 +01:00
|
|
|
if (!(commit->object.flags & TREECHANGE))
|
Make path-limiting be incremental when possible.
This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.
This makes things like "git log -- pathname" much more pleasant to use.
This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.
What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".
This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.
The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing
git-rev-list HEAD -- drivers/char/ | md5sum
before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.
Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing
git log drivers/
on the kernel archive, or even better, on the _historic_ kernel archive.
With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.
NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.
MAYBE we can fix that too at some point, but I won't promise anything.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-31 03:05:25 +02:00
|
|
|
continue;
|
|
|
|
if (revs->parents)
|
Make "--parents" logs also be incremental
The parent rewriting feature caused us to create the whole history in one
go, and then simplify it later, because of how rewrite_parents() had been
written. However, with a little tweaking, it's perfectly possible to do
even that one incrementally.
Right now, this doesn't really much matter, because every user of
"--parents" will probably generally _also_ use "--topo-order", which will
cause the old non-incremental behaviour anyway. However, I'm hopeful that
we could make even the topological sort incremental, or at least
_partially_ so (for example, make it incremental up to the first merge).
In the meantime, this at least moves things in the right direction, and
removes a strange special case.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-09 02:05:58 +02:00
|
|
|
rewrite_parents(revs, commit);
|
2006-03-28 09:58:34 +02:00
|
|
|
}
|
2006-04-17 03:12:49 +02:00
|
|
|
if (revs->boundary)
|
|
|
|
mark_boundary_to_show(commit);
|
2006-03-01 00:07:20 +01:00
|
|
|
commit->object.flags |= SHOWN;
|
|
|
|
return commit;
|
|
|
|
} while (revs->commits);
|
|
|
|
return NULL;
|
|
|
|
}
|