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"
|
2008-05-04 12:36:54 +02:00
|
|
|
#include "graph.h"
|
2006-09-18 00:43:40 +02:00
|
|
|
#include "grep.h"
|
2007-01-11 11:47:48 +01:00
|
|
|
#include "reflog-walk.h"
|
2007-04-09 12:40:38 +02:00
|
|
|
#include "patch-ids.h"
|
2008-04-03 11:12:06 +02:00
|
|
|
#include "decorate.h"
|
2008-11-03 20:25:46 +01:00
|
|
|
#include "log-tree.h"
|
2010-03-12 18:04:26 +01:00
|
|
|
#include "string-list.h"
|
2013-01-05 22:26:45 +01:00
|
|
|
#include "mailmap.h"
|
2006-02-26 01:19:46 +01:00
|
|
|
|
2007-11-03 19:11:10 +01:00
|
|
|
volatile show_early_output_fn_t show_early_output;
|
|
|
|
|
show_object(): push path_name() call further down
In particular, pushing the "path_name()" call _into_ the show() function
would seem to allow
- more clarity into who "owns" the name (ie now when we free the name in
the show_object callback, it's because we generated it ourselves by
calling path_name())
- not calling path_name() at all, either because we don't care about the
name in the first place, or because we are actually happy walking the
linked list of "struct name_path *" and the last component.
Now, I didn't do that latter optimization, because it would require some
more coding, but especially looking at "builtin-pack-objects.c", we really
don't even want the whole pathname, we really would be better off with the
list of path components.
Why? We use that name for two things:
- add_preferred_base_object(), which actually _wants_ to traverse the
path, and now does it by looking for '/' characters!
- for 'name_hash()', which only cares about the last 16 characters of a
name, so again, generating the full name seems to be just unnecessary
work.
Anyway, so I didn't look any closer at those things, but it did convince
me that the "show_object()" calling convention was crazy, and we're
actually better off doing _less_ in list-objects.c, and giving people
access to the internal data structures so that they can decide whether
they want to generate a path-name or not.
This patch does that, and then for people who did use the name (even if
they might do something more clever in the future), it just does the
straightforward "name = path_name(path, component); .. free(name);" thing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 03:15:26 +02:00
|
|
|
char *path_name(const struct name_path *path, const char *name)
|
2006-02-26 01:19:46 +01:00
|
|
|
{
|
show_object(): push path_name() call further down
In particular, pushing the "path_name()" call _into_ the show() function
would seem to allow
- more clarity into who "owns" the name (ie now when we free the name in
the show_object callback, it's because we generated it ourselves by
calling path_name())
- not calling path_name() at all, either because we don't care about the
name in the first place, or because we are actually happy walking the
linked list of "struct name_path *" and the last component.
Now, I didn't do that latter optimization, because it would require some
more coding, but especially looking at "builtin-pack-objects.c", we really
don't even want the whole pathname, we really would be better off with the
list of path components.
Why? We use that name for two things:
- add_preferred_base_object(), which actually _wants_ to traverse the
path, and now does it by looking for '/' characters!
- for 'name_hash()', which only cares about the last 16 characters of a
name, so again, generating the full name seems to be just unnecessary
work.
Anyway, so I didn't look any closer at those things, but it did convince
me that the "show_object()" calling convention was crazy, and we're
actually better off doing _less_ in list-objects.c, and giving people
access to the internal data structures so that they can decide whether
they want to generate a path-name or not.
This patch does that, and then for people who did use the name (even if
they might do something more clever in the future), it just does the
straightforward "name = path_name(path, component); .. free(name);" thing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 03:15:26 +02:00
|
|
|
const struct name_path *p;
|
2006-02-26 01:19:46 +01:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2011-08-17 23:30:35 +02:00
|
|
|
static int show_path_component_truncated(FILE *out, const char *name, int len)
|
|
|
|
{
|
|
|
|
int cnt;
|
|
|
|
for (cnt = 0; cnt < len; cnt++) {
|
|
|
|
int ch = name[cnt];
|
|
|
|
if (!ch || ch == '\n')
|
|
|
|
return -1;
|
|
|
|
fputc(ch, out);
|
|
|
|
}
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int show_path_truncated(FILE *out, const struct name_path *path)
|
|
|
|
{
|
|
|
|
int emitted, ours;
|
|
|
|
|
|
|
|
if (!path)
|
|
|
|
return 0;
|
|
|
|
emitted = show_path_truncated(out, path->up);
|
|
|
|
if (emitted < 0)
|
|
|
|
return emitted;
|
|
|
|
if (emitted)
|
|
|
|
fputc('/', out);
|
|
|
|
ours = show_path_component_truncated(out, path->elem, path->elem_len);
|
|
|
|
if (ours < 0)
|
|
|
|
return ours;
|
|
|
|
return ours || emitted;
|
|
|
|
}
|
|
|
|
|
2011-08-17 23:30:34 +02:00
|
|
|
void show_object_with_name(FILE *out, struct object *obj, const struct name_path *path, const char *component)
|
|
|
|
{
|
2011-08-17 23:30:35 +02:00
|
|
|
struct name_path leaf;
|
|
|
|
leaf.up = (struct name_path *)path;
|
|
|
|
leaf.elem = component;
|
|
|
|
leaf.elem_len = strlen(component);
|
2011-08-17 23:30:34 +02:00
|
|
|
|
2011-08-17 23:30:35 +02:00
|
|
|
fprintf(out, "%s ", sha1_to_hex(obj->sha1));
|
|
|
|
show_path_truncated(out, &leaf);
|
|
|
|
fputc('\n', out);
|
2011-08-17 23:30:34 +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
|
|
|
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)
|
|
|
|
{
|
2008-02-18 21:47:54 +01:00
|
|
|
if (!blob)
|
|
|
|
return;
|
2006-02-26 01:19:46 +01:00
|
|
|
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;
|
|
|
|
|
2008-02-18 21:47:54 +01:00
|
|
|
if (!tree)
|
|
|
|
return;
|
2006-02-26 01:19:46 +01:00
|
|
|
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
|
|
|
|
2007-03-21 18:08:25 +01:00
|
|
|
init_tree_desc(&desc, tree->buffer, 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)) {
|
2007-11-12 00:35:23 +01:00
|
|
|
switch (object_type(entry.mode)) {
|
|
|
|
case OBJ_TREE:
|
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_tree_uninteresting(lookup_tree(entry.sha1));
|
2007-11-12 00:35:23 +01:00
|
|
|
break;
|
|
|
|
case OBJ_BLOB:
|
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));
|
2007-11-12 00:35:23 +01:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* Subproject commit - not in this repository */
|
|
|
|
break;
|
|
|
|
}
|
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)
|
|
|
|
{
|
2012-01-14 13:19:53 +01:00
|
|
|
struct commit_list *parents = NULL, *l;
|
|
|
|
|
|
|
|
for (l = commit->parents; l; l = l->next)
|
|
|
|
commit_list_insert(l->item, &parents);
|
2006-02-26 01:19:46 +01:00
|
|
|
|
|
|
|
while (parents) {
|
|
|
|
struct commit *commit = parents->item;
|
2012-01-14 13:19:53 +01:00
|
|
|
l = parents;
|
|
|
|
parents = parents->next;
|
|
|
|
free(l);
|
|
|
|
|
|
|
|
while (commit) {
|
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
|
|
|
|
if (commit->object.flags & UNINTERESTING)
|
|
|
|
break;
|
|
|
|
|
2006-03-09 05:04:36 +01:00
|
|
|
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..
|
|
|
|
*/
|
2012-01-14 13:19:53 +01:00
|
|
|
if (!commit->parents)
|
|
|
|
break;
|
2006-02-26 01:19:46 +01:00
|
|
|
|
2012-01-14 13:19:53 +01:00
|
|
|
for (l = commit->parents->next; l; l = l->next)
|
|
|
|
commit_list_insert(l->item, &parents);
|
|
|
|
commit = commit->parents->item;
|
|
|
|
}
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-06-08 11:24:58 +02:00
|
|
|
static void add_pending_object_with_mode(struct rev_info *revs, struct object *obj, const char *name, unsigned mode)
|
2006-02-26 01:19:46 +01:00
|
|
|
{
|
2011-05-19 03:08:09 +02:00
|
|
|
if (!obj)
|
|
|
|
return;
|
2007-02-28 01:22:52 +01:00
|
|
|
if (revs->no_walk && (obj->flags & UNINTERESTING))
|
Make 'git show' more useful
For some reason, I ended up doing
git show HEAD~5..
as an odd way of asking for a log. I realize I should just have used "git
log", but at the same time it does make perfect conceptual sense. After
all, you _could_ have done
git show HEAD HEAD~1 HEAD~2 HEAD~3 HEAD~4
and saying "git show HEAD~5.." is pretty natural. It's not like "git show"
only ever showed a single commit (or other object) before either! So
conceptually, giving a commit range is a very sensible operation, even
though you'd traditionally have used "git log" for that.
However, doing that currently results in an error
fatal: object ranges do not make sense when not walking revisions
which admittedly _also_ makes perfect sense - from an internal git
implementation standpoint in 'revision.c'.
However, I think that asking to show a range makes sense to a user, while
saying "object ranges no not make sense when not walking revisions" only
makes sense to a git developer.
So on the whole, of the two different "makes perfect sense" behaviors, I
think I originally picked the wrong one. And quite frankly, I don't really
see anybody actually _depending_ on that error case. So why not change it?
So rather than error out, just turn that non-walking error case into a
"silently turn on walking" instead.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-13 23:41:12 +02:00
|
|
|
revs->no_walk = 0;
|
2010-01-26 22:48:28 +01:00
|
|
|
if (revs->reflog_info && obj->type == OBJ_COMMIT) {
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
int len = interpret_branch_name(name, &buf);
|
|
|
|
int st;
|
|
|
|
|
|
|
|
if (0 < len && name[len] && buf.len)
|
|
|
|
strbuf_addstr(&buf, name + len);
|
|
|
|
st = add_reflog_for_walk(revs->reflog_info,
|
|
|
|
(struct commit *)obj,
|
|
|
|
buf.buf[0] ? buf.buf: name);
|
|
|
|
strbuf_release(&buf);
|
|
|
|
if (st)
|
|
|
|
return;
|
|
|
|
}
|
2007-04-22 18:43:59 +02:00
|
|
|
add_object_array_with_mode(obj, name, &revs->pending, mode);
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
|
|
|
|
2007-06-08 11:24:58 +02:00
|
|
|
void add_pending_object(struct rev_info *revs, struct object *obj, const char *name)
|
|
|
|
{
|
|
|
|
add_pending_object_with_mode(revs, obj, name, S_IFINVALID);
|
|
|
|
}
|
|
|
|
|
2007-12-11 19:09:04 +01:00
|
|
|
void add_head_to_pending(struct rev_info *revs)
|
|
|
|
{
|
|
|
|
unsigned char sha1[20];
|
|
|
|
struct object *obj;
|
|
|
|
if (get_sha1("HEAD", sha1))
|
|
|
|
return;
|
|
|
|
obj = parse_object(sha1);
|
|
|
|
if (!obj)
|
|
|
|
return;
|
|
|
|
add_pending_object(revs, obj, "HEAD");
|
|
|
|
}
|
|
|
|
|
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);
|
2011-05-19 03:08:09 +02:00
|
|
|
if (!object) {
|
|
|
|
if (revs->ignore_missing)
|
|
|
|
return object;
|
2006-02-26 01:19:46 +01:00
|
|
|
die("bad object %s", name);
|
2011-05-19 03:08:09 +02: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
|
|
|
object->flags |= flags;
|
|
|
|
return object;
|
|
|
|
}
|
|
|
|
|
2011-10-01 17:43:52 +02:00
|
|
|
void add_pending_sha1(struct rev_info *revs, const char *name,
|
|
|
|
const unsigned char *sha1, unsigned int flags)
|
|
|
|
{
|
|
|
|
struct object *object = get_reference(revs, name, sha1, flags);
|
|
|
|
add_pending_object(revs, object, 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
|
|
|
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..
|
|
|
|
*/
|
2006-07-12 05:45:31 +02:00
|
|
|
while (object->type == OBJ_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);
|
2008-02-18 21:48:01 +01:00
|
|
|
if (!tag->tagged)
|
|
|
|
die("bad tag");
|
2006-02-26 01:19:46 +01:00
|
|
|
object = parse_object(tag->tagged->sha1);
|
2009-01-28 08:19:30 +01:00
|
|
|
if (!object) {
|
|
|
|
if (flags & UNINTERESTING)
|
|
|
|
return NULL;
|
2006-02-26 01:19:46 +01:00
|
|
|
die("bad object %s", sha1_to_hex(tag->tagged->sha1));
|
2009-01-28 08:19:30 +01:00
|
|
|
}
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Commit object? Just return it, we'll do all the complex
|
|
|
|
* reachability crud.
|
|
|
|
*/
|
2006-07-12 05:45:31 +02:00
|
|
|
if (object->type == OBJ_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;
|
|
|
|
}
|
2008-10-27 20:51:59 +01:00
|
|
|
if (revs->show_source && !commit->util)
|
|
|
|
commit->util = (void *) name;
|
2006-02-26 01:19:46 +01:00
|
|
|
return commit;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2009-04-17 20:13:30 +02:00
|
|
|
* Tree object? Either mark it uninteresting, or add it
|
2006-02-26 01:19:46 +01:00
|
|
|
* to the list of objects to look at later..
|
|
|
|
*/
|
2006-07-12 05:45:31 +02:00
|
|
|
if (object->type == OBJ_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..
|
|
|
|
*/
|
2006-07-12 05:45:31 +02:00
|
|
|
if (object->type == OBJ_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;
|
|
|
|
}
|
|
|
|
|
2007-03-14 21:12:18 +01:00
|
|
|
/*
|
|
|
|
* The goal is to get REV_TREE_NEW as the result only if the
|
2009-06-03 03:34:01 +02:00
|
|
|
* diff consists of all '+' (and no other changes), REV_TREE_OLD
|
|
|
|
* if the whole diff is removal of old data, and otherwise
|
|
|
|
* REV_TREE_DIFFERENT (of course if the trees are the same we
|
|
|
|
* want REV_TREE_SAME).
|
|
|
|
* That means that once we get to REV_TREE_DIFFERENT, we do not
|
|
|
|
* have to look any further.
|
2007-03-14 21:12:18 +01:00
|
|
|
*/
|
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,
|
diff: do not use null sha1 as a sentinel value
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 17:03:01 +02:00
|
|
|
int sha1_valid,
|
2010-01-18 21:26:18 +01:00
|
|
|
const char *fullpath, unsigned dirty_submodule)
|
2006-02-28 20:24:00 +01:00
|
|
|
{
|
2009-06-03 03:34:01 +02:00
|
|
|
int diff = addremove == '+' ? REV_TREE_NEW : REV_TREE_OLD;
|
2006-02-28 20:24:00 +01:00
|
|
|
|
2009-06-03 03:34:01 +02:00
|
|
|
tree_difference |= diff;
|
2007-03-14 21:18:15 +01:00
|
|
|
if (tree_difference == REV_TREE_DIFFERENT)
|
2007-11-10 20:05:14 +01:00
|
|
|
DIFF_OPT_SET(options, HAS_CHANGES);
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void file_change(struct diff_options *options,
|
|
|
|
unsigned old_mode, unsigned new_mode,
|
|
|
|
const unsigned char *old_sha1,
|
|
|
|
const unsigned char *new_sha1,
|
diff: do not use null sha1 as a sentinel value
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 17:03:01 +02:00
|
|
|
int old_sha1_valid, int new_sha1_valid,
|
2010-01-18 21:26:18 +01:00
|
|
|
const char *fullpath,
|
|
|
|
unsigned old_dirty_submodule, unsigned new_dirty_submodule)
|
2006-02-28 20:24:00 +01:00
|
|
|
{
|
2006-03-10 10:21:39 +01:00
|
|
|
tree_difference = REV_TREE_DIFFERENT;
|
2007-11-10 20:05:14 +01:00
|
|
|
DIFF_OPT_SET(options, HAS_CHANGES);
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
|
2008-11-03 19:45:41 +01:00
|
|
|
static int rev_compare_tree(struct rev_info *revs, struct commit *parent, struct commit *commit)
|
2006-02-28 20:24:00 +01:00
|
|
|
{
|
2008-11-03 19:45:41 +01:00
|
|
|
struct tree *t1 = parent->tree;
|
|
|
|
struct tree *t2 = commit->tree;
|
|
|
|
|
2006-02-28 20:24:00 +01:00
|
|
|
if (!t1)
|
2006-03-10 10:21:39 +01:00
|
|
|
return REV_TREE_NEW;
|
2009-06-03 03:34:01 +02:00
|
|
|
if (!t2)
|
|
|
|
return REV_TREE_OLD;
|
2008-11-03 20:25:46 +01:00
|
|
|
|
|
|
|
if (revs->simplify_by_decoration) {
|
|
|
|
/*
|
|
|
|
* If we are simplifying by decoration, then the commit
|
|
|
|
* is worth showing if it has a tag pointing at it.
|
|
|
|
*/
|
|
|
|
if (lookup_decoration(&name_decoration, &commit->object))
|
|
|
|
return REV_TREE_DIFFERENT;
|
|
|
|
/*
|
|
|
|
* A commit that is not pointed by a tag is uninteresting
|
|
|
|
* if we are not limited by path. This means that you will
|
|
|
|
* see the usual "commits that touch the paths" plus any
|
|
|
|
* tagged commit by specifying both --simplify-by-decoration
|
|
|
|
* and pathspec.
|
|
|
|
*/
|
2010-12-17 13:43:06 +01:00
|
|
|
if (!revs->prune_data.nr)
|
2008-11-03 20:25:46 +01:00
|
|
|
return REV_TREE_SAME;
|
|
|
|
}
|
2009-06-03 03:34:01 +02:00
|
|
|
|
2006-03-10 10:21:39 +01:00
|
|
|
tree_difference = REV_TREE_SAME;
|
2007-11-10 20:05:14 +01:00
|
|
|
DIFF_OPT_CLR(&revs->pruning, HAS_CHANGES);
|
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;
|
|
|
|
}
|
|
|
|
|
2008-11-03 19:45:41 +01:00
|
|
|
static int rev_same_tree_as_empty(struct rev_info *revs, struct commit *commit)
|
2006-02-28 20:24:00 +01:00
|
|
|
{
|
|
|
|
int retval;
|
|
|
|
void *tree;
|
2007-03-21 18:08:25 +01:00
|
|
|
unsigned long size;
|
2006-02-28 20:24:00 +01:00
|
|
|
struct tree_desc empty, real;
|
2008-11-03 19:45:41 +01:00
|
|
|
struct tree *t1 = commit->tree;
|
2006-02-28 20:24:00 +01:00
|
|
|
|
|
|
|
if (!t1)
|
|
|
|
return 0;
|
|
|
|
|
2007-03-21 18:08:25 +01:00
|
|
|
tree = read_object_with_reference(t1->object.sha1, tree_type, &size, NULL);
|
2006-02-28 20:24:00 +01:00
|
|
|
if (!tree)
|
|
|
|
return 0;
|
2007-03-21 18:08:25 +01:00
|
|
|
init_tree_desc(&real, tree, size);
|
|
|
|
init_tree_desc(&empty, "", 0);
|
2006-02-28 20:24:00 +01:00
|
|
|
|
2007-03-14 21:12:18 +01:00
|
|
|
tree_difference = REV_TREE_SAME;
|
2007-11-10 20:05:14 +01:00
|
|
|
DIFF_OPT_CLR(&revs->pruning, HAS_CHANGES);
|
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);
|
|
|
|
|
2007-03-14 21:12:18 +01:00
|
|
|
return retval >= 0 && (tree_difference == REV_TREE_SAME);
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
|
|
|
|
{
|
|
|
|
struct commit_list **pp, *parent;
|
Making pathspec limited log play nicer with --first-parent
In a topic branch workflow, you often want to find the latest commit that
merged a side branch that touched a particular area of the system, so that
a new topic branch to work on that area can be forked from that commit.
For example, I wanted to find an appropriate fork-point to queue Luke's
changes related to git-p4 in contrib/fast-import/.
"git log --first-parent" traverses the first-parent chain, and "-m --stat"
shows the list of paths touched by commits including merge commits. We
could ask the question this way:
# What is the latest commit that touched that path?
$ git log --first-parent --oneline -m --stat master |
sed -e '/^ contrib\/fast-import\/git-p4 /q' | tail
The above finds that 8cbfc11 (Merge branch 'pw/p4-view-updates',
2012-01-06) was such a commit.
But a more natural way to spell this question is this:
$ git log --first-parent --oneline -m --stat -1 master -- \
contrib/fast-import/git-p4
Unfortunately, this does not work. It finds ecb7cf9 (git-p4: rewrite view
handling, 2012-01-02). This commit is a part of the merged topic branch
and is _not_ on the first-parent path from the 'master':
$ git show-branch 8cbfc11 ecb7cf9
! [8cbfc11] Merge branch 'pw/p4-view-updates'
! [ecb7cf9] git-p4: rewrite view handling
--
- [8cbfc11] Merge branch 'pw/p4-view-updates'
+ [8cbfc11^2] git-p4: view spec documentation
++ [ecb7cf9] git-p4: rewrite view handling
The problem is caused by the merge simplification logic when it inspects
the merge commit 8cbfc11. In this case, the history leading to the tip of
'master' did not touch git-p4 since 'pw/p4-view-updates' topic forked, and
the result of the merge is simply a copy from the tip of the topic branch
in the view limited by the given pathspec. The merge simplification logic
discards the history on the mainline side of the merge, and pretends as if
the sole parent of the merge is its second parent, i.e. the tip of the
topic. While this simplification is correct in the general case, it is at
least surprising if not outright wrong when the user explicitly asked to
show the first-parent history.
Here is an attempt to fix this issue, by not allowing us to compare the
merge result with anything but the first parent when --first-parent is in
effect, to avoid the history traversal veering off to the side branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-19 20:58:45 +01:00
|
|
|
int tree_changed = 0, tree_same = 0, nth_parent = 0;
|
2006-02-28 20:24:00 +01:00
|
|
|
|
2007-11-05 22:22:34 +01:00
|
|
|
/*
|
|
|
|
* If we don't do pruning, everything is interesting
|
|
|
|
*/
|
2007-11-13 08:16:08 +01:00
|
|
|
if (!revs->prune)
|
2007-11-05 22:22:34 +01:00
|
|
|
return;
|
|
|
|
|
2006-02-28 20:24:00 +01:00
|
|
|
if (!commit->tree)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!commit->parents) {
|
2008-11-03 19:45:41 +01:00
|
|
|
if (rev_same_tree_as_empty(revs, commit))
|
2007-11-13 08:16:08 +01:00
|
|
|
commit->object.flags |= TREESAME;
|
2006-02-28 20:24:00 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2007-11-05 22:22:34 +01:00
|
|
|
/*
|
|
|
|
* Normal non-merge commit? If we don't want to make the
|
|
|
|
* history dense, we consider it always to be a change..
|
|
|
|
*/
|
2007-11-13 08:16:08 +01:00
|
|
|
if (!revs->dense && !commit->parents->next)
|
2007-11-05 22:22:34 +01:00
|
|
|
return;
|
|
|
|
|
2006-02-28 20:24:00 +01:00
|
|
|
pp = &commit->parents;
|
|
|
|
while ((parent = *pp) != NULL) {
|
|
|
|
struct commit *p = parent->item;
|
|
|
|
|
Making pathspec limited log play nicer with --first-parent
In a topic branch workflow, you often want to find the latest commit that
merged a side branch that touched a particular area of the system, so that
a new topic branch to work on that area can be forked from that commit.
For example, I wanted to find an appropriate fork-point to queue Luke's
changes related to git-p4 in contrib/fast-import/.
"git log --first-parent" traverses the first-parent chain, and "-m --stat"
shows the list of paths touched by commits including merge commits. We
could ask the question this way:
# What is the latest commit that touched that path?
$ git log --first-parent --oneline -m --stat master |
sed -e '/^ contrib\/fast-import\/git-p4 /q' | tail
The above finds that 8cbfc11 (Merge branch 'pw/p4-view-updates',
2012-01-06) was such a commit.
But a more natural way to spell this question is this:
$ git log --first-parent --oneline -m --stat -1 master -- \
contrib/fast-import/git-p4
Unfortunately, this does not work. It finds ecb7cf9 (git-p4: rewrite view
handling, 2012-01-02). This commit is a part of the merged topic branch
and is _not_ on the first-parent path from the 'master':
$ git show-branch 8cbfc11 ecb7cf9
! [8cbfc11] Merge branch 'pw/p4-view-updates'
! [ecb7cf9] git-p4: rewrite view handling
--
- [8cbfc11] Merge branch 'pw/p4-view-updates'
+ [8cbfc11^2] git-p4: view spec documentation
++ [ecb7cf9] git-p4: rewrite view handling
The problem is caused by the merge simplification logic when it inspects
the merge commit 8cbfc11. In this case, the history leading to the tip of
'master' did not touch git-p4 since 'pw/p4-view-updates' topic forked, and
the result of the merge is simply a copy from the tip of the topic branch
in the view limited by the given pathspec. The merge simplification logic
discards the history on the mainline side of the merge, and pretends as if
the sole parent of the merge is its second parent, i.e. the tip of the
topic. While this simplification is correct in the general case, it is at
least surprising if not outright wrong when the user explicitly asked to
show the first-parent history.
Here is an attempt to fix this issue, by not allowing us to compare the
merge result with anything but the first parent when --first-parent is in
effect, to avoid the history traversal veering off to the side branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-19 20:58:45 +01:00
|
|
|
/*
|
|
|
|
* Do not compare with later parents when we care only about
|
|
|
|
* the first parent chain, in order to avoid derailing the
|
|
|
|
* traversal to follow a side branch that brought everything
|
|
|
|
* in the path we are limited to by the pathspec.
|
|
|
|
*/
|
|
|
|
if (revs->first_parent_only && nth_parent++)
|
|
|
|
break;
|
2007-05-04 23:54:57 +02:00
|
|
|
if (parse_commit(p) < 0)
|
|
|
|
die("cannot simplify commit %s (because of %s)",
|
|
|
|
sha1_to_hex(commit->object.sha1),
|
|
|
|
sha1_to_hex(p->object.sha1));
|
2008-11-03 19:45:41 +01:00
|
|
|
switch (rev_compare_tree(revs, p, commit)) {
|
2006-03-10 10:21:39 +01:00
|
|
|
case REV_TREE_SAME:
|
2006-07-01 05:21:59 +02:00
|
|
|
tree_same = 1;
|
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;
|
2007-11-13 08:16:08 +01:00
|
|
|
commit->object.flags |= TREESAME;
|
2006-02-28 20:24:00 +01:00
|
|
|
return;
|
|
|
|
|
2006-03-10 10:21:39 +01:00
|
|
|
case REV_TREE_NEW:
|
|
|
|
if (revs->remove_empty_trees &&
|
2008-11-03 19:45:41 +01:00
|
|
|
rev_same_tree_as_empty(revs, p)) {
|
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
|
|
|
*/
|
2007-05-04 23:54:57 +02:00
|
|
|
if (parse_commit(p) < 0)
|
|
|
|
die("cannot simplify commit %s (invalid %s)",
|
|
|
|
sha1_to_hex(commit->object.sha1),
|
|
|
|
sha1_to_hex(p->object.sha1));
|
2006-03-12 22:39:31 +01:00
|
|
|
p->parents = NULL;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
/* fallthrough */
|
2009-06-03 03:34:01 +02:00
|
|
|
case REV_TREE_OLD:
|
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-07-01 05:21:59 +02:00
|
|
|
if (tree_changed && !tree_same)
|
2007-11-13 08:16:08 +01:00
|
|
|
return;
|
|
|
|
commit->object.flags |= TREESAME;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
|
2010-11-27 02:58:14 +01:00
|
|
|
static void commit_list_insert_by_date_cached(struct commit *p, struct commit_list **head,
|
2008-07-12 20:00:57 +02:00
|
|
|
struct commit_list *cached_base, struct commit_list **cache)
|
|
|
|
{
|
|
|
|
struct commit_list *new_entry;
|
|
|
|
|
|
|
|
if (cached_base && p->date < cached_base->item->date)
|
2010-11-27 02:58:14 +01:00
|
|
|
new_entry = commit_list_insert_by_date(p, &cached_base->next);
|
2008-07-12 20:00:57 +02:00
|
|
|
else
|
2010-11-27 02:58:14 +01:00
|
|
|
new_entry = commit_list_insert_by_date(p, head);
|
2008-07-12 20:00:57 +02:00
|
|
|
|
|
|
|
if (cache && (!*cache || p->date < (*cache)->item->date))
|
|
|
|
*cache = new_entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int add_parents_to_list(struct rev_info *revs, struct commit *commit,
|
|
|
|
struct commit_list **list, struct commit_list **cache_ptr)
|
2006-02-28 20:24:00 +01:00
|
|
|
{
|
|
|
|
struct commit_list *parent = commit->parents;
|
2006-10-23 02:32:47 +02:00
|
|
|
unsigned left_flag;
|
2008-07-12 20:00:57 +02:00
|
|
|
struct commit_list *cached_base = cache_ptr ? *cache_ptr : NULL;
|
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
|
|
|
if (commit->object.flags & ADDED)
|
2007-05-04 23:54:57 +02:00
|
|
|
return 0;
|
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
|
|
|
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;
|
2009-01-28 08:19:30 +01:00
|
|
|
if (p)
|
|
|
|
p->object.flags |= UNINTERESTING;
|
2007-05-04 23:54:57 +02:00
|
|
|
if (parse_commit(p) < 0)
|
2009-01-28 08:19:30 +01:00
|
|
|
continue;
|
2006-02-28 20:24:00 +01:00
|
|
|
if (p->parents)
|
|
|
|
mark_parents_uninteresting(p);
|
|
|
|
if (p->object.flags & SEEN)
|
|
|
|
continue;
|
|
|
|
p->object.flags |= SEEN;
|
2010-11-27 02:58:14 +01:00
|
|
|
commit_list_insert_by_date_cached(p, list, cached_base, cache_ptr);
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
2007-05-04 23:54:57 +02:00
|
|
|
return 0;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
2007-11-05 22:22:34 +01:00
|
|
|
try_to_simplify_commit(revs, commit);
|
2006-02-28 20:24:00 +01:00
|
|
|
|
2006-04-15 21:09:56 +02:00
|
|
|
if (revs->no_walk)
|
2007-05-04 23:54:57 +02:00
|
|
|
return 0;
|
2006-04-15 21:09:56 +02:00
|
|
|
|
2006-10-23 02:32:47 +02:00
|
|
|
left_flag = (commit->object.flags & SYMMETRIC_LEFT);
|
2007-03-13 09:57:22 +01:00
|
|
|
|
2008-04-27 19:32:46 +02:00
|
|
|
for (parent = commit->parents; parent; parent = parent->next) {
|
2006-02-28 20:24:00 +01:00
|
|
|
struct commit *p = parent->item;
|
|
|
|
|
2007-05-04 23:54:57 +02:00
|
|
|
if (parse_commit(p) < 0)
|
|
|
|
return -1;
|
2008-10-27 20:51:59 +01:00
|
|
|
if (revs->show_source && !p->util)
|
|
|
|
p->util = commit->util;
|
2006-10-23 02:32:47 +02:00
|
|
|
p->object.flags |= left_flag;
|
2008-05-12 17:12:36 +02:00
|
|
|
if (!(p->object.flags & SEEN)) {
|
|
|
|
p->object.flags |= SEEN;
|
2010-11-27 02:58:14 +01:00
|
|
|
commit_list_insert_by_date_cached(p, list, cached_base, cache_ptr);
|
2008-05-12 17:12:36 +02:00
|
|
|
}
|
2008-08-01 07:17:13 +02:00
|
|
|
if (revs->first_parent_only)
|
2008-04-27 19:32:46 +02:00
|
|
|
break;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
2007-05-04 23:54:57 +02:00
|
|
|
return 0;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
|
2007-07-10 15:50:49 +02:00
|
|
|
static void cherry_pick_list(struct commit_list *list, struct rev_info *revs)
|
2007-04-09 12:40:38 +02:00
|
|
|
{
|
|
|
|
struct commit_list *p;
|
|
|
|
int left_count = 0, right_count = 0;
|
|
|
|
int left_first;
|
|
|
|
struct patch_ids ids;
|
2011-03-07 13:31:40 +01:00
|
|
|
unsigned cherry_flag;
|
2007-04-09 12:40:38 +02:00
|
|
|
|
|
|
|
/* First count the commits on the left and on the right */
|
|
|
|
for (p = list; p; p = p->next) {
|
|
|
|
struct commit *commit = p->item;
|
|
|
|
unsigned flags = commit->object.flags;
|
|
|
|
if (flags & BOUNDARY)
|
|
|
|
;
|
|
|
|
else if (flags & SYMMETRIC_LEFT)
|
|
|
|
left_count++;
|
|
|
|
else
|
|
|
|
right_count++;
|
|
|
|
}
|
|
|
|
|
2010-02-20 12:42:04 +01:00
|
|
|
if (!left_count || !right_count)
|
|
|
|
return;
|
|
|
|
|
2007-04-09 12:40:38 +02:00
|
|
|
left_first = left_count < right_count;
|
|
|
|
init_patch_ids(&ids);
|
2010-12-15 16:02:38 +01:00
|
|
|
ids.diffopts.pathspec = revs->diffopt.pathspec;
|
2007-04-09 12:40:38 +02:00
|
|
|
|
|
|
|
/* Compute patch-ids for one side */
|
|
|
|
for (p = list; p; p = p->next) {
|
|
|
|
struct commit *commit = p->item;
|
|
|
|
unsigned flags = commit->object.flags;
|
|
|
|
|
|
|
|
if (flags & BOUNDARY)
|
|
|
|
continue;
|
|
|
|
/*
|
|
|
|
* If we have fewer left, left_first is set and we omit
|
|
|
|
* commits on the right branch in this loop. If we have
|
|
|
|
* fewer right, we skip the left ones.
|
|
|
|
*/
|
|
|
|
if (left_first != !!(flags & SYMMETRIC_LEFT))
|
|
|
|
continue;
|
|
|
|
commit->util = add_commit_patch_id(commit, &ids);
|
|
|
|
}
|
|
|
|
|
2011-03-07 13:31:40 +01:00
|
|
|
/* either cherry_mark or cherry_pick are true */
|
|
|
|
cherry_flag = revs->cherry_mark ? PATCHSAME : SHOWN;
|
|
|
|
|
2007-04-09 12:40:38 +02:00
|
|
|
/* Check the other side */
|
|
|
|
for (p = list; p; p = p->next) {
|
|
|
|
struct commit *commit = p->item;
|
|
|
|
struct patch_id *id;
|
|
|
|
unsigned flags = commit->object.flags;
|
|
|
|
|
|
|
|
if (flags & BOUNDARY)
|
|
|
|
continue;
|
|
|
|
/*
|
|
|
|
* If we have fewer left, left_first is set and we omit
|
|
|
|
* commits on the left branch in this loop.
|
|
|
|
*/
|
|
|
|
if (left_first == !!(flags & SYMMETRIC_LEFT))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Have we seen the same patch id?
|
|
|
|
*/
|
|
|
|
id = has_commit_patch_id(commit, &ids);
|
|
|
|
if (!id)
|
|
|
|
continue;
|
|
|
|
id->seen = 1;
|
2011-03-07 13:31:40 +01:00
|
|
|
commit->object.flags |= cherry_flag;
|
2007-04-09 12:40:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Now check the original side for seen ones */
|
|
|
|
for (p = list; p; p = p->next) {
|
|
|
|
struct commit *commit = p->item;
|
|
|
|
struct patch_id *ent;
|
|
|
|
|
|
|
|
ent = commit->util;
|
|
|
|
if (!ent)
|
|
|
|
continue;
|
|
|
|
if (ent->seen)
|
2011-03-07 13:31:40 +01:00
|
|
|
commit->object.flags |= cherry_flag;
|
2007-04-09 12:40:38 +02:00
|
|
|
commit->util = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
free_patch_ids(&ids);
|
|
|
|
}
|
|
|
|
|
2008-03-18 02:56:33 +01:00
|
|
|
/* How many extra uninteresting commits we want to see.. */
|
|
|
|
#define SLOP 5
|
|
|
|
|
|
|
|
static int still_interesting(struct commit_list *src, unsigned long date, int slop)
|
Add "--show-all" revision walker flag for debugging
It's really not very easy to visualize the commit walker, because - on
purpose - it obvously doesn't show the uninteresting commits!
This adds a "--show-all" flag to the revision walker, which will make
it show uninteresting commits too, and they'll have a '^' in front of
them (it also fixes a logic error for !verbose_header for boundary
commits - we should show the '-' even if left_right isn't shown).
A separate patch to gitk to teach it the new '^' was sent
to paulus. With the change in place, it actually is interesting
even for the cases that git doesn't have any problems with, ie
for the kernel you can do:
gitk -d --show-all v2.6.24..
and you see just how far down it has to parse things to see it all. The
use of "-d" is a good idea, since the date-ordered toposort is much better
at showing why it goes deep down (ie the date of some of those commits
after 2.6.24 is much older, because they were merged from trees that
weren't rebased).
So I think this is a useful feature even for non-debugging - just to
visualize what git does internally more.
When it actually breaks out due to the "everybody_uninteresting()"
case, it adds the uninteresting commits (both the one it's looking at
now, and the list of pending ones) to the list
This way, we really list *all* the commits we've looked at.
Because we now end up listing commits we may not even have been parsed
at all "show_log" and "show_commit" need to protect against commits
that don't have a commit buffer entry.
That second part is debatable just how it should work. Maybe we shouldn't
show such entries at all (with this patch those entries do get shown, they
just don't get any message shown with them). But I think this is a useful
case.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-09 23:02:07 +01:00
|
|
|
{
|
2008-03-18 02:56:33 +01:00
|
|
|
/*
|
|
|
|
* No source list at all? We're definitely done..
|
|
|
|
*/
|
|
|
|
if (!src)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Does the destination list contain entries with a date
|
|
|
|
* before the source list? Definitely _not_ done.
|
|
|
|
*/
|
2013-03-22 19:38:19 +01:00
|
|
|
if (date <= src->item->date)
|
2008-03-18 02:56:33 +01:00
|
|
|
return SLOP;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Does the source list still have interesting commits in
|
|
|
|
* it? Definitely not done..
|
|
|
|
*/
|
|
|
|
if (!everybody_uninteresting(src))
|
|
|
|
return SLOP;
|
|
|
|
|
|
|
|
/* Ok, we're closing in.. */
|
|
|
|
return slop-1;
|
Add "--show-all" revision walker flag for debugging
It's really not very easy to visualize the commit walker, because - on
purpose - it obvously doesn't show the uninteresting commits!
This adds a "--show-all" flag to the revision walker, which will make
it show uninteresting commits too, and they'll have a '^' in front of
them (it also fixes a logic error for !verbose_header for boundary
commits - we should show the '-' even if left_right isn't shown).
A separate patch to gitk to teach it the new '^' was sent
to paulus. With the change in place, it actually is interesting
even for the cases that git doesn't have any problems with, ie
for the kernel you can do:
gitk -d --show-all v2.6.24..
and you see just how far down it has to parse things to see it all. The
use of "-d" is a good idea, since the date-ordered toposort is much better
at showing why it goes deep down (ie the date of some of those commits
after 2.6.24 is much older, because they were merged from trees that
weren't rebased).
So I think this is a useful feature even for non-debugging - just to
visualize what git does internally more.
When it actually breaks out due to the "everybody_uninteresting()"
case, it adds the uninteresting commits (both the one it's looking at
now, and the list of pending ones) to the list
This way, we really list *all* the commits we've looked at.
Because we now end up listing commits we may not even have been parsed
at all "show_log" and "show_commit" need to protect against commits
that don't have a commit buffer entry.
That second part is debatable just how it should work. Maybe we shouldn't
show such entries at all (with this patch those entries do get shown, they
just don't get any message shown with them). But I think this is a useful
case.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-09 23:02:07 +01:00
|
|
|
}
|
|
|
|
|
revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 22:48:39 +02:00
|
|
|
/*
|
|
|
|
* "rev-list --ancestry-path A..B" computes commits that are ancestors
|
|
|
|
* of B but not ancestors of A but further limits the result to those
|
|
|
|
* that are descendants of A. This takes the list of bottom commits and
|
|
|
|
* the result of "A..B" without --ancestry-path, and limits the latter
|
|
|
|
* further to the ones that can reach one of the commits in "bottom".
|
|
|
|
*/
|
|
|
|
static void limit_to_ancestry(struct commit_list *bottom, struct commit_list *list)
|
|
|
|
{
|
|
|
|
struct commit_list *p;
|
|
|
|
struct commit_list *rlist = NULL;
|
|
|
|
int made_progress;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reverse the list so that it will be likely that we would
|
|
|
|
* process parents before children.
|
|
|
|
*/
|
|
|
|
for (p = list; p; p = p->next)
|
|
|
|
commit_list_insert(p->item, &rlist);
|
|
|
|
|
|
|
|
for (p = bottom; p; p = p->next)
|
|
|
|
p->item->object.flags |= TMP_MARK;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Mark the ones that can reach bottom commits in "list",
|
|
|
|
* in a bottom-up fashion.
|
|
|
|
*/
|
|
|
|
do {
|
|
|
|
made_progress = 0;
|
|
|
|
for (p = rlist; p; p = p->next) {
|
|
|
|
struct commit *c = p->item;
|
|
|
|
struct commit_list *parents;
|
|
|
|
if (c->object.flags & (TMP_MARK | UNINTERESTING))
|
|
|
|
continue;
|
|
|
|
for (parents = c->parents;
|
|
|
|
parents;
|
|
|
|
parents = parents->next) {
|
|
|
|
if (!(parents->item->object.flags & TMP_MARK))
|
|
|
|
continue;
|
|
|
|
c->object.flags |= TMP_MARK;
|
|
|
|
made_progress = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} while (made_progress);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NEEDSWORK: decide if we want to remove parents that are
|
|
|
|
* not marked with TMP_MARK from commit->parents for commits
|
|
|
|
* in the resulting list. We may not want to do that, though.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The ones that are not marked with TMP_MARK are uninteresting
|
|
|
|
*/
|
|
|
|
for (p = list; p; p = p->next) {
|
|
|
|
struct commit *c = p->item;
|
|
|
|
if (c->object.flags & TMP_MARK)
|
|
|
|
continue;
|
|
|
|
c->object.flags |= UNINTERESTING;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We are done with the TMP_MARK */
|
|
|
|
for (p = list; p; p = p->next)
|
|
|
|
p->item->object.flags &= ~TMP_MARK;
|
|
|
|
for (p = bottom; p; p = p->next)
|
|
|
|
p->item->object.flags &= ~TMP_MARK;
|
|
|
|
free_commit_list(rlist);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Before walking the history, keep the set of "negative" refs the
|
|
|
|
* caller has asked to exclude.
|
|
|
|
*
|
|
|
|
* This is used to compute "rev-list --ancestry-path A..B", as we need
|
|
|
|
* to filter the result of "A..B" further to the ones that can actually
|
|
|
|
* reach A.
|
|
|
|
*/
|
2011-08-26 02:51:50 +02:00
|
|
|
static struct commit_list *collect_bottom_commits(struct rev_info *revs)
|
revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 22:48:39 +02:00
|
|
|
{
|
2011-08-26 02:51:50 +02:00
|
|
|
struct commit_list *bottom = NULL;
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < revs->cmdline.nr; i++) {
|
|
|
|
struct rev_cmdline_entry *elem = &revs->cmdline.rev[i];
|
|
|
|
if ((elem->flags & UNINTERESTING) &&
|
|
|
|
elem->item->type == OBJ_COMMIT)
|
|
|
|
commit_list_insert((struct commit *)elem->item, &bottom);
|
|
|
|
}
|
revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 22:48:39 +02:00
|
|
|
return bottom;
|
|
|
|
}
|
|
|
|
|
2011-02-21 17:09:11 +01:00
|
|
|
/* Assumes either left_only or right_only is set */
|
|
|
|
static void limit_left_right(struct commit_list *list, struct rev_info *revs)
|
|
|
|
{
|
|
|
|
struct commit_list *p;
|
|
|
|
|
|
|
|
for (p = list; p; p = p->next) {
|
|
|
|
struct commit *commit = p->item;
|
|
|
|
|
|
|
|
if (revs->right_only) {
|
|
|
|
if (commit->object.flags & SYMMETRIC_LEFT)
|
|
|
|
commit->object.flags |= SHOWN;
|
|
|
|
} else /* revs->left_only is set */
|
|
|
|
if (!(commit->object.flags & SYMMETRIC_LEFT))
|
|
|
|
commit->object.flags |= SHOWN;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-05-04 23:54:57 +02:00
|
|
|
static int limit_list(struct rev_info *revs)
|
2006-02-28 20:24:00 +01:00
|
|
|
{
|
2008-03-18 02:56:33 +01:00
|
|
|
int slop = SLOP;
|
|
|
|
unsigned long date = ~0ul;
|
2006-02-28 20:24:00 +01:00
|
|
|
struct commit_list *list = revs->commits;
|
|
|
|
struct commit_list *newlist = NULL;
|
|
|
|
struct commit_list **p = &newlist;
|
revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 22:48:39 +02:00
|
|
|
struct commit_list *bottom = NULL;
|
|
|
|
|
|
|
|
if (revs->ancestry_path) {
|
2011-08-26 02:51:50 +02:00
|
|
|
bottom = collect_bottom_commits(revs);
|
revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 22:48:39 +02:00
|
|
|
if (!bottom)
|
2010-06-04 01:17:36 +02:00
|
|
|
die("--ancestry-path given but there are no bottom commits");
|
revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 22:48:39 +02:00
|
|
|
}
|
2006-02-28 20:24:00 +01:00
|
|
|
|
|
|
|
while (list) {
|
|
|
|
struct commit_list *entry = list;
|
|
|
|
struct commit *commit = list->item;
|
|
|
|
struct object *obj = &commit->object;
|
2007-11-03 19:11:10 +01:00
|
|
|
show_early_output_fn_t show;
|
2006-02-28 20:24:00 +01:00
|
|
|
|
|
|
|
list = list->next;
|
|
|
|
free(entry);
|
|
|
|
|
|
|
|
if (revs->max_age != -1 && (commit->date < revs->max_age))
|
|
|
|
obj->flags |= UNINTERESTING;
|
2008-07-12 20:00:57 +02:00
|
|
|
if (add_parents_to_list(revs, commit, &list, NULL) < 0)
|
2007-05-04 23:54:57 +02:00
|
|
|
return -1;
|
2006-02-28 20:24:00 +01:00
|
|
|
if (obj->flags & UNINTERESTING) {
|
|
|
|
mark_parents_uninteresting(commit);
|
2008-03-18 02:56:33 +01:00
|
|
|
if (revs->show_all)
|
|
|
|
p = &commit_list_insert(commit, p)->next;
|
|
|
|
slop = still_interesting(list, date, slop);
|
|
|
|
if (slop)
|
Add "--show-all" revision walker flag for debugging
It's really not very easy to visualize the commit walker, because - on
purpose - it obvously doesn't show the uninteresting commits!
This adds a "--show-all" flag to the revision walker, which will make
it show uninteresting commits too, and they'll have a '^' in front of
them (it also fixes a logic error for !verbose_header for boundary
commits - we should show the '-' even if left_right isn't shown).
A separate patch to gitk to teach it the new '^' was sent
to paulus. With the change in place, it actually is interesting
even for the cases that git doesn't have any problems with, ie
for the kernel you can do:
gitk -d --show-all v2.6.24..
and you see just how far down it has to parse things to see it all. The
use of "-d" is a good idea, since the date-ordered toposort is much better
at showing why it goes deep down (ie the date of some of those commits
after 2.6.24 is much older, because they were merged from trees that
weren't rebased).
So I think this is a useful feature even for non-debugging - just to
visualize what git does internally more.
When it actually breaks out due to the "everybody_uninteresting()"
case, it adds the uninteresting commits (both the one it's looking at
now, and the list of pending ones) to the list
This way, we really list *all* the commits we've looked at.
Because we now end up listing commits we may not even have been parsed
at all "show_log" and "show_commit" need to protect against commits
that don't have a commit buffer entry.
That second part is debatable just how it should work. Maybe we shouldn't
show such entries at all (with this patch those entries do get shown, they
just don't get any message shown with them). But I think this is a useful
case.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-09 23:02:07 +01:00
|
|
|
continue;
|
2008-03-18 02:56:33 +01:00
|
|
|
/* If showing all, add the whole pending list to the end */
|
|
|
|
if (revs->show_all)
|
|
|
|
*p = list;
|
|
|
|
break;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
if (revs->min_age != -1 && (commit->date > revs->min_age))
|
|
|
|
continue;
|
2008-03-18 02:56:33 +01:00
|
|
|
date = commit->date;
|
2006-02-28 20:24:00 +01:00
|
|
|
p = &commit_list_insert(commit, p)->next;
|
2007-11-03 19:11:10 +01:00
|
|
|
|
|
|
|
show = show_early_output;
|
|
|
|
if (!show)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
show(revs, newlist);
|
|
|
|
show_early_output = NULL;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
2011-03-07 13:31:40 +01:00
|
|
|
if (revs->cherry_pick || revs->cherry_mark)
|
2007-07-10 15:50:49 +02:00
|
|
|
cherry_pick_list(newlist, revs);
|
2007-04-09 12:40:38 +02:00
|
|
|
|
2011-02-21 17:09:11 +01:00
|
|
|
if (revs->left_only || revs->right_only)
|
|
|
|
limit_left_right(newlist, revs);
|
|
|
|
|
revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 22:48:39 +02:00
|
|
|
if (bottom) {
|
|
|
|
limit_to_ancestry(bottom, newlist);
|
|
|
|
free_commit_list(bottom);
|
|
|
|
}
|
|
|
|
|
2006-02-28 20:24:00 +01:00
|
|
|
revs->commits = newlist;
|
2007-05-04 23:54:57 +02:00
|
|
|
return 0;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
|
2011-08-26 02:35:39 +02:00
|
|
|
static void add_rev_cmdline(struct rev_info *revs,
|
|
|
|
struct object *item,
|
|
|
|
const char *name,
|
|
|
|
int whence,
|
|
|
|
unsigned flags)
|
|
|
|
{
|
|
|
|
struct rev_cmdline_info *info = &revs->cmdline;
|
|
|
|
int nr = info->nr;
|
|
|
|
|
|
|
|
ALLOC_GROW(info->rev, nr + 1, info->alloc);
|
|
|
|
info->rev[nr].item = item;
|
|
|
|
info->rev[nr].name = name;
|
|
|
|
info->rev[nr].whence = whence;
|
|
|
|
info->rev[nr].flags = flags;
|
|
|
|
info->nr++;
|
|
|
|
}
|
|
|
|
|
2006-12-19 02:25:28 +01:00
|
|
|
struct all_refs_cb {
|
|
|
|
int all_flags;
|
2006-12-22 01:49:06 +01:00
|
|
|
int warned_bad_reflog;
|
2006-12-19 02:25:28 +01:00
|
|
|
struct rev_info *all_revs;
|
|
|
|
const char *name_for_errormsg;
|
|
|
|
};
|
2006-02-26 01:19:46 +01:00
|
|
|
|
2006-09-21 07:02:01 +02:00
|
|
|
static int handle_one_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
|
2006-02-26 01:19:46 +01:00
|
|
|
{
|
2006-12-19 02:25:28 +01:00
|
|
|
struct all_refs_cb *cb = cb_data;
|
|
|
|
struct object *object = get_reference(cb->all_revs, path, sha1,
|
|
|
|
cb->all_flags);
|
2011-08-26 02:35:39 +02:00
|
|
|
add_rev_cmdline(cb->all_revs, object, path, REV_CMD_REF, cb->all_flags);
|
2011-10-01 17:43:52 +02:00
|
|
|
add_pending_sha1(cb->all_revs, path, sha1, cb->all_flags);
|
2006-02-26 01:19:46 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-01-20 10:48:25 +01:00
|
|
|
static void init_all_refs_cb(struct all_refs_cb *cb, struct rev_info *revs,
|
|
|
|
unsigned flags)
|
|
|
|
{
|
|
|
|
cb->all_revs = revs;
|
|
|
|
cb->all_flags = flags;
|
|
|
|
}
|
|
|
|
|
2010-07-07 15:39:12 +02:00
|
|
|
static void handle_refs(const char *submodule, struct rev_info *revs, unsigned flags,
|
|
|
|
int (*for_each)(const char *, each_ref_fn, void *))
|
2006-02-26 01:19:46 +01:00
|
|
|
{
|
2006-12-19 02:25:28 +01:00
|
|
|
struct all_refs_cb cb;
|
2010-01-20 10:48:25 +01:00
|
|
|
init_all_refs_cb(&cb, revs, flags);
|
2010-07-07 15:39:12 +02:00
|
|
|
for_each(submodule, handle_one_ref, &cb);
|
2006-12-19 02:25:28 +01:00
|
|
|
}
|
|
|
|
|
2006-12-22 01:49:06 +01:00
|
|
|
static void handle_one_reflog_commit(unsigned char *sha1, void *cb_data)
|
2006-12-19 02:25:28 +01:00
|
|
|
{
|
|
|
|
struct all_refs_cb *cb = cb_data;
|
2006-12-22 01:49:06 +01:00
|
|
|
if (!is_null_sha1(sha1)) {
|
|
|
|
struct object *o = parse_object(sha1);
|
|
|
|
if (o) {
|
|
|
|
o->flags |= cb->all_flags;
|
2011-08-26 02:35:39 +02:00
|
|
|
/* ??? CMDLINEFLAGS ??? */
|
2006-12-22 01:49:06 +01:00
|
|
|
add_pending_object(cb->all_revs, o, "");
|
|
|
|
}
|
|
|
|
else if (!cb->warned_bad_reflog) {
|
2007-03-31 01:07:05 +02:00
|
|
|
warning("reflog of '%s' references pruned commits",
|
2006-12-22 01:49:06 +01:00
|
|
|
cb->name_for_errormsg);
|
|
|
|
cb->warned_bad_reflog = 1;
|
|
|
|
}
|
2006-12-19 02:25:28 +01:00
|
|
|
}
|
2006-12-22 01:49:06 +01:00
|
|
|
}
|
|
|
|
|
2007-01-08 01:59:54 +01:00
|
|
|
static int handle_one_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
|
|
|
|
const char *email, unsigned long timestamp, int tz,
|
|
|
|
const char *message, void *cb_data)
|
2006-12-22 01:49:06 +01:00
|
|
|
{
|
|
|
|
handle_one_reflog_commit(osha1, cb_data);
|
|
|
|
handle_one_reflog_commit(nsha1, cb_data);
|
2006-12-19 02:25:28 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int handle_one_reflog(const char *path, const unsigned char *sha1, int flag, void *cb_data)
|
|
|
|
{
|
|
|
|
struct all_refs_cb *cb = cb_data;
|
2006-12-22 01:49:06 +01:00
|
|
|
cb->warned_bad_reflog = 0;
|
2006-12-19 02:25:28 +01:00
|
|
|
cb->name_for_errormsg = path;
|
|
|
|
for_each_reflog_ent(path, handle_one_reflog_ent, cb_data);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void handle_reflog(struct rev_info *revs, unsigned flags)
|
|
|
|
{
|
|
|
|
struct all_refs_cb cb;
|
|
|
|
cb.all_revs = revs;
|
|
|
|
cb.all_flags = flags;
|
2007-02-13 08:06:54 +01:00
|
|
|
for_each_reflog(handle_one_reflog, &cb);
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
|
|
|
|
2011-08-26 02:35:39 +02:00
|
|
|
static int add_parents_only(struct rev_info *revs, const char *arg_, int flags)
|
2006-04-30 09:54:29 +02:00
|
|
|
{
|
|
|
|
unsigned char sha1[20];
|
|
|
|
struct object *it;
|
|
|
|
struct commit *commit;
|
|
|
|
struct commit_list *parents;
|
2011-08-26 02:35:39 +02:00
|
|
|
const char *arg = arg_;
|
2006-04-30 09:54:29 +02:00
|
|
|
|
|
|
|
if (*arg == '^') {
|
|
|
|
flags ^= UNINTERESTING;
|
|
|
|
arg++;
|
|
|
|
}
|
2012-07-02 21:04:52 +02:00
|
|
|
if (get_sha1_committish(arg, sha1))
|
2006-04-30 09:54:29 +02:00
|
|
|
return 0;
|
|
|
|
while (1) {
|
|
|
|
it = get_reference(revs, arg, sha1, 0);
|
2011-05-19 03:08:09 +02:00
|
|
|
if (!it && revs->ignore_missing)
|
|
|
|
return 0;
|
2006-07-12 05:45:31 +02:00
|
|
|
if (it->type != OBJ_TAG)
|
2006-04-30 09:54:29 +02:00
|
|
|
break;
|
2008-02-18 21:48:01 +01:00
|
|
|
if (!((struct tag*)it)->tagged)
|
|
|
|
return 0;
|
2006-08-23 08:49:00 +02:00
|
|
|
hashcpy(sha1, ((struct tag*)it)->tagged->sha1);
|
2006-04-30 09:54:29 +02:00
|
|
|
}
|
2006-07-12 05:45:31 +02:00
|
|
|
if (it->type != OBJ_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;
|
2011-08-26 02:35:39 +02:00
|
|
|
add_rev_cmdline(revs, it, arg_, REV_CMD_PARENTS_ONLY, flags);
|
2006-04-30 09:54:29 +02:00
|
|
|
add_pending_object(revs, it, arg);
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2006-07-29 06:21:48 +02:00
|
|
|
void init_revisions(struct rev_info *revs, const char *prefix)
|
2006-03-10 10:21:39 +01:00
|
|
|
{
|
|
|
|
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;
|
2007-11-10 20:05:14 +01:00
|
|
|
DIFF_OPT_SET(&revs->pruning, RECURSIVE);
|
2009-05-23 10:15:35 +02:00
|
|
|
DIFF_OPT_SET(&revs->pruning, QUICK);
|
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.add_remove = file_add_remove;
|
|
|
|
revs->pruning.change = file_change;
|
2006-03-10 10:21:39 +01:00
|
|
|
revs->lifo = 1;
|
|
|
|
revs->dense = 1;
|
2006-07-29 06:21:48 +02:00
|
|
|
revs->prefix = prefix;
|
2006-03-10 10:21:39 +01:00
|
|
|
revs->max_age = -1;
|
|
|
|
revs->min_age = -1;
|
2006-12-20 03:25:32 +01:00
|
|
|
revs->skip_count = -1;
|
2006-03-10 10:21:39 +01:00
|
|
|
revs->max_count = -1;
|
2011-03-21 11:14:06 +01:00
|
|
|
revs->max_parents = -1;
|
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
|
|
|
revs->commit_format = CMIT_FMT_DEFAULT;
|
|
|
|
|
2012-10-10 01:40:03 +02:00
|
|
|
init_grep_defaults();
|
|
|
|
grep_init(&revs->grep_filter, prefix);
|
2008-08-25 08:15:05 +02:00
|
|
|
revs->grep_filter.status_only = 1;
|
|
|
|
revs->grep_filter.regflags = REG_NEWLINE;
|
|
|
|
|
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_setup(&revs->diffopt);
|
2008-02-13 09:34:39 +01:00
|
|
|
if (prefix && !revs->diffopt.prefix) {
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-12 23:26:02 +01:00
|
|
|
revs->diffopt.prefix = prefix;
|
|
|
|
revs->diffopt.prefix_length = strlen(prefix);
|
|
|
|
}
|
2011-03-29 22:57:27 +02:00
|
|
|
|
|
|
|
revs->notes_opt.use_default_notes = -1;
|
2006-03-10 10:21:39 +01:00
|
|
|
}
|
|
|
|
|
2006-07-02 01:29:37 +02:00
|
|
|
static void add_pending_commit_list(struct rev_info *revs,
|
|
|
|
struct commit_list *commit_list,
|
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
while (commit_list) {
|
|
|
|
struct object *object = &commit_list->item->object;
|
|
|
|
object->flags |= flags;
|
|
|
|
add_pending_object(revs, object, sha1_to_hex(object->sha1));
|
|
|
|
commit_list = commit_list->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-07-03 11:59:32 +02:00
|
|
|
static void prepare_show_merge(struct rev_info *revs)
|
|
|
|
{
|
|
|
|
struct commit_list *bases;
|
|
|
|
struct commit *head, *other;
|
|
|
|
unsigned char sha1[20];
|
|
|
|
const char **prune = NULL;
|
|
|
|
int i, prune_num = 1; /* counting terminating NULL */
|
|
|
|
|
2011-09-17 13:57:45 +02:00
|
|
|
if (get_sha1("HEAD", sha1))
|
2006-07-03 11:59:32 +02:00
|
|
|
die("--merge without HEAD?");
|
2011-09-17 13:57:45 +02:00
|
|
|
head = lookup_commit_or_die(sha1, "HEAD");
|
|
|
|
if (get_sha1("MERGE_HEAD", sha1))
|
2006-07-03 11:59:32 +02:00
|
|
|
die("--merge without MERGE_HEAD?");
|
2011-09-17 13:57:45 +02:00
|
|
|
other = lookup_commit_or_die(sha1, "MERGE_HEAD");
|
2006-07-03 11:59:32 +02:00
|
|
|
add_pending_object(revs, &head->object, "HEAD");
|
|
|
|
add_pending_object(revs, &other->object, "MERGE_HEAD");
|
|
|
|
bases = get_merge_bases(head, other, 1);
|
2008-02-27 08:18:38 +01:00
|
|
|
add_pending_commit_list(revs, bases, UNINTERESTING);
|
|
|
|
free_commit_list(bases);
|
|
|
|
head->object.flags |= SYMMETRIC_LEFT;
|
2006-07-03 11:59:32 +02:00
|
|
|
|
|
|
|
if (!active_nr)
|
|
|
|
read_cache();
|
|
|
|
for (i = 0; i < active_nr; i++) {
|
|
|
|
struct cache_entry *ce = active_cache[i];
|
|
|
|
if (!ce_stage(ce))
|
|
|
|
continue;
|
2010-12-17 13:43:07 +01:00
|
|
|
if (ce_path_match(ce, &revs->prune_data)) {
|
2006-07-03 11:59:32 +02:00
|
|
|
prune_num++;
|
|
|
|
prune = xrealloc(prune, sizeof(*prune) * prune_num);
|
|
|
|
prune[prune_num-2] = ce->name;
|
|
|
|
prune[prune_num-1] = NULL;
|
|
|
|
}
|
|
|
|
while ((i+1 < active_nr) &&
|
|
|
|
ce_same_name(ce, active_cache[i+1]))
|
|
|
|
i++;
|
|
|
|
}
|
2010-12-17 13:43:06 +01:00
|
|
|
free_pathspec(&revs->prune_data);
|
|
|
|
init_pathspec(&revs->prune_data, prune);
|
2008-02-27 08:18:38 +01:00
|
|
|
revs->limited = 1;
|
2006-07-03 11:59:32 +02:00
|
|
|
}
|
|
|
|
|
2012-07-02 21:33:52 +02:00
|
|
|
int handle_revision_arg(const char *arg_, struct rev_info *revs, int flags, unsigned revarg_opt)
|
2006-09-06 06:28:36 +02:00
|
|
|
{
|
2012-07-02 21:56:44 +02:00
|
|
|
struct object_context oc;
|
2006-09-06 06:28:36 +02:00
|
|
|
char *dotdot;
|
|
|
|
struct object *object;
|
|
|
|
unsigned char sha1[20];
|
|
|
|
int local_flags;
|
2011-08-26 02:35:39 +02:00
|
|
|
const char *arg = arg_;
|
2012-07-02 21:33:52 +02:00
|
|
|
int cant_be_filename = revarg_opt & REVARG_CANNOT_BE_FILENAME;
|
2012-07-02 21:43:05 +02:00
|
|
|
unsigned get_sha1_flags = 0;
|
2006-09-06 06:28:36 +02:00
|
|
|
|
|
|
|
dotdot = strstr(arg, "..");
|
|
|
|
if (dotdot) {
|
|
|
|
unsigned char from_sha1[20];
|
|
|
|
const char *next = dotdot + 2;
|
|
|
|
const char *this = arg;
|
|
|
|
int symmetric = *next == '.';
|
|
|
|
unsigned int flags_exclude = flags ^ UNINTERESTING;
|
2011-05-02 22:39:16 +02:00
|
|
|
static const char head_by_default[] = "HEAD";
|
2011-08-26 02:35:39 +02:00
|
|
|
unsigned int a_flags;
|
2006-09-06 06:28:36 +02:00
|
|
|
|
|
|
|
*dotdot = 0;
|
|
|
|
next += symmetric;
|
|
|
|
|
|
|
|
if (!*next)
|
2011-05-02 22:39:16 +02:00
|
|
|
next = head_by_default;
|
2006-09-06 06:28:36 +02:00
|
|
|
if (dotdot == arg)
|
2011-05-02 22:39:16 +02:00
|
|
|
this = head_by_default;
|
|
|
|
if (this == head_by_default && next == head_by_default &&
|
|
|
|
!symmetric) {
|
|
|
|
/*
|
|
|
|
* Just ".."? That is not a range but the
|
|
|
|
* pathspec for the parent directory.
|
|
|
|
*/
|
|
|
|
if (!cant_be_filename) {
|
|
|
|
*dotdot = '.';
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
2012-07-02 21:04:52 +02:00
|
|
|
if (!get_sha1_committish(this, from_sha1) &&
|
|
|
|
!get_sha1_committish(next, sha1)) {
|
2006-09-06 06:28:36 +02:00
|
|
|
struct commit *a, *b;
|
|
|
|
struct commit_list *exclude;
|
|
|
|
|
|
|
|
a = lookup_commit_reference(from_sha1);
|
|
|
|
b = lookup_commit_reference(sha1);
|
|
|
|
if (!a || !b) {
|
2011-05-19 03:08:09 +02:00
|
|
|
if (revs->ignore_missing)
|
|
|
|
return 0;
|
2006-09-06 06:28:36 +02:00
|
|
|
die(symmetric ?
|
|
|
|
"Invalid symmetric difference expression %s...%s" :
|
|
|
|
"Invalid revision range %s..%s",
|
|
|
|
arg, next);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!cant_be_filename) {
|
|
|
|
*dotdot = '.';
|
|
|
|
verify_non_filename(revs->prefix, arg);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (symmetric) {
|
|
|
|
exclude = get_merge_bases(a, b, 1);
|
|
|
|
add_pending_commit_list(revs, exclude,
|
|
|
|
flags_exclude);
|
|
|
|
free_commit_list(exclude);
|
2011-08-26 02:35:39 +02:00
|
|
|
a_flags = flags | SYMMETRIC_LEFT;
|
2006-09-06 06:28:36 +02:00
|
|
|
} else
|
2011-08-26 02:35:39 +02:00
|
|
|
a_flags = flags_exclude;
|
|
|
|
a->object.flags |= a_flags;
|
2006-09-06 06:28:36 +02:00
|
|
|
b->object.flags |= flags;
|
2011-08-26 02:35:39 +02:00
|
|
|
add_rev_cmdline(revs, &a->object, this,
|
|
|
|
REV_CMD_LEFT, a_flags);
|
|
|
|
add_rev_cmdline(revs, &b->object, next,
|
|
|
|
REV_CMD_RIGHT, flags);
|
2006-09-06 06:28:36 +02:00
|
|
|
add_pending_object(revs, &a->object, this);
|
|
|
|
add_pending_object(revs, &b->object, next);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
*dotdot = '.';
|
|
|
|
}
|
|
|
|
dotdot = strstr(arg, "^@");
|
|
|
|
if (dotdot && !dotdot[2]) {
|
|
|
|
*dotdot = 0;
|
|
|
|
if (add_parents_only(revs, arg, flags))
|
|
|
|
return 0;
|
|
|
|
*dotdot = '^';
|
|
|
|
}
|
2006-10-31 23:22:34 +01:00
|
|
|
dotdot = strstr(arg, "^!");
|
|
|
|
if (dotdot && !dotdot[2]) {
|
|
|
|
*dotdot = 0;
|
|
|
|
if (!add_parents_only(revs, arg, flags ^ UNINTERESTING))
|
|
|
|
*dotdot = '^';
|
|
|
|
}
|
|
|
|
|
2006-09-06 06:28:36 +02:00
|
|
|
local_flags = 0;
|
|
|
|
if (*arg == '^') {
|
|
|
|
local_flags = UNINTERESTING;
|
|
|
|
arg++;
|
|
|
|
}
|
2012-07-02 21:43:05 +02:00
|
|
|
|
|
|
|
if (revarg_opt & REVARG_COMMITTISH)
|
|
|
|
get_sha1_flags = GET_SHA1_COMMITTISH;
|
|
|
|
|
|
|
|
if (get_sha1_with_context(arg, get_sha1_flags, sha1, &oc))
|
2011-05-19 03:08:09 +02:00
|
|
|
return revs->ignore_missing ? 0 : -1;
|
2006-09-06 06:28:36 +02:00
|
|
|
if (!cant_be_filename)
|
|
|
|
verify_non_filename(revs->prefix, arg);
|
|
|
|
object = get_reference(revs, arg, sha1, flags ^ local_flags);
|
2011-08-26 02:35:39 +02:00
|
|
|
add_rev_cmdline(revs, object, arg_, REV_CMD_REV, flags ^ local_flags);
|
2012-07-02 21:56:44 +02:00
|
|
|
add_pending_object_with_mode(revs, object, arg, oc.mode);
|
2006-09-06 06:28:36 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-05-11 23:01:19 +02:00
|
|
|
struct cmdline_pathspec {
|
|
|
|
int alloc;
|
|
|
|
int nr;
|
|
|
|
const char **path;
|
|
|
|
};
|
2008-07-05 23:26:39 +02:00
|
|
|
|
2011-05-11 23:01:19 +02:00
|
|
|
static void append_prune_data(struct cmdline_pathspec *prune, const char **av)
|
|
|
|
{
|
|
|
|
while (*av) {
|
|
|
|
ALLOC_GROW(prune->path, prune->nr+1, prune->alloc);
|
|
|
|
prune->path[prune->nr++] = *(av++);
|
|
|
|
}
|
|
|
|
}
|
2009-11-20 11:50:21 +01:00
|
|
|
|
2011-05-11 23:01:19 +02:00
|
|
|
static void read_pathspec_from_stdin(struct rev_info *revs, struct strbuf *sb,
|
|
|
|
struct cmdline_pathspec *prune)
|
|
|
|
{
|
2009-11-20 11:50:21 +01:00
|
|
|
while (strbuf_getwholeline(sb, stdin, '\n') != EOF) {
|
|
|
|
int len = sb->len;
|
|
|
|
if (len && sb->buf[len - 1] == '\n')
|
|
|
|
sb->buf[--len] = '\0';
|
2011-05-11 23:01:19 +02:00
|
|
|
ALLOC_GROW(prune->path, prune->nr+1, prune->alloc);
|
|
|
|
prune->path[prune->nr++] = xstrdup(sb->buf);
|
2009-11-20 11:50:21 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-05-11 23:01:19 +02:00
|
|
|
static void read_revisions_from_stdin(struct rev_info *revs,
|
|
|
|
struct cmdline_pathspec *prune)
|
2008-07-05 23:26:39 +02:00
|
|
|
{
|
2009-11-20 11:00:40 +01:00
|
|
|
struct strbuf sb;
|
2009-11-20 11:50:21 +01:00
|
|
|
int seen_dashdash = 0;
|
2008-07-05 23:26:39 +02:00
|
|
|
|
2009-11-20 11:00:40 +01:00
|
|
|
strbuf_init(&sb, 1000);
|
|
|
|
while (strbuf_getwholeline(&sb, stdin, '\n') != EOF) {
|
|
|
|
int len = sb.len;
|
|
|
|
if (len && sb.buf[len - 1] == '\n')
|
|
|
|
sb.buf[--len] = '\0';
|
2008-07-05 23:26:39 +02:00
|
|
|
if (!len)
|
|
|
|
break;
|
2009-11-20 11:50:21 +01:00
|
|
|
if (sb.buf[0] == '-') {
|
|
|
|
if (len == 2 && sb.buf[1] == '-') {
|
|
|
|
seen_dashdash = 1;
|
|
|
|
break;
|
|
|
|
}
|
2008-07-05 23:26:39 +02:00
|
|
|
die("options not supported in --stdin mode");
|
2009-11-20 11:50:21 +01:00
|
|
|
}
|
2013-04-16 11:57:45 +02:00
|
|
|
if (handle_revision_arg(xstrdup(sb.buf), revs, 0,
|
|
|
|
REVARG_CANNOT_BE_FILENAME))
|
2009-11-20 11:00:40 +01:00
|
|
|
die("bad revision '%s'", sb.buf);
|
2008-07-05 23:26:39 +02:00
|
|
|
}
|
2009-11-20 11:50:21 +01:00
|
|
|
if (seen_dashdash)
|
|
|
|
read_pathspec_from_stdin(revs, &sb, prune);
|
2009-11-20 11:00:40 +01:00
|
|
|
strbuf_release(&sb);
|
2008-07-05 23:26:39 +02:00
|
|
|
}
|
|
|
|
|
2006-09-20 22:21:56 +02:00
|
|
|
static void add_grep(struct rev_info *revs, const char *ptn, enum grep_pat_token what)
|
2006-09-18 02:23:20 +02:00
|
|
|
{
|
2008-08-25 08:15:05 +02:00
|
|
|
append_grep_pattern(&revs->grep_filter, ptn, "command line", 0, what);
|
2006-09-20 22:21:56 +02:00
|
|
|
}
|
|
|
|
|
log --author/--committer: really match only with name part
When we tried to find commits done by AUTHOR, the first implementation
tried to pattern match a line with "^author .*AUTHOR", which later was
enhanced to strip leading caret and look for "^author AUTHOR" when the
search pattern was anchored at the left end (i.e. --author="^AUTHOR").
This had a few problems:
* When looking for fixed strings (e.g. "git log -F --author=x --grep=y"),
the regexp internally used "^author .*x" would never match anything;
* To match at the end (e.g. "git log --author='google.com>$'"), the
generated regexp has to also match the trailing timestamp part the
commit header lines have. Also, in order to determine if the '$' at
the end means "match at the end of the line" or just a literal dollar
sign (probably backslash-quoted), we would need to parse the regexp
ourselves.
An earlier alternative tried to make sure that a line matches "^author "
(to limit by field name) and the user supplied pattern at the same time.
While it solved the -F problem by introducing a special override for
matching the "^author ", it did not solve the trailing timestamp nor tail
match problem. It also would have matched every commit if --author=author
was asked for, not because the author's email part had this string, but
because every commit header line that talks about the author begins with
that field name, regardleses of who wrote it.
Instead of piling more hacks on top of hacks, this rethinks the grep
machinery that is used to look for strings in the commit header, and makes
sure that (1) field name matches literally at the beginning of the line,
followed by a SP, and (2) the user supplied pattern is matched against the
remainder of the line, excluding the trailing timestamp data.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-05 07:15:02 +02:00
|
|
|
static void add_header_grep(struct rev_info *revs, enum grep_header_field field, const char *pattern)
|
2006-09-20 22:21:56 +02:00
|
|
|
{
|
log --author/--committer: really match only with name part
When we tried to find commits done by AUTHOR, the first implementation
tried to pattern match a line with "^author .*AUTHOR", which later was
enhanced to strip leading caret and look for "^author AUTHOR" when the
search pattern was anchored at the left end (i.e. --author="^AUTHOR").
This had a few problems:
* When looking for fixed strings (e.g. "git log -F --author=x --grep=y"),
the regexp internally used "^author .*x" would never match anything;
* To match at the end (e.g. "git log --author='google.com>$'"), the
generated regexp has to also match the trailing timestamp part the
commit header lines have. Also, in order to determine if the '$' at
the end means "match at the end of the line" or just a literal dollar
sign (probably backslash-quoted), we would need to parse the regexp
ourselves.
An earlier alternative tried to make sure that a line matches "^author "
(to limit by field name) and the user supplied pattern at the same time.
While it solved the -F problem by introducing a special override for
matching the "^author ", it did not solve the trailing timestamp nor tail
match problem. It also would have matched every commit if --author=author
was asked for, not because the author's email part had this string, but
because every commit header line that talks about the author begins with
that field name, regardleses of who wrote it.
Instead of piling more hacks on top of hacks, this rethinks the grep
machinery that is used to look for strings in the commit header, and makes
sure that (1) field name matches literally at the beginning of the line,
followed by a SP, and (2) the user supplied pattern is matched against the
remainder of the line, excluding the trailing timestamp data.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-05 07:15:02 +02:00
|
|
|
append_header_grep_pattern(&revs->grep_filter, field, pattern);
|
2006-09-18 02:23:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void add_message_grep(struct rev_info *revs, const char *pattern)
|
|
|
|
{
|
2006-09-20 22:21:56 +02:00
|
|
|
add_grep(revs, pattern, GREP_PATTERN_BODY);
|
2006-09-18 02:23:20 +02:00
|
|
|
}
|
|
|
|
|
2008-07-09 23:38:34 +02:00
|
|
|
static int handle_revision_opt(struct rev_info *revs, int argc, const char **argv,
|
|
|
|
int *unkc, const char **unkv)
|
2008-07-08 15:19:33 +02:00
|
|
|
{
|
|
|
|
const char *arg = argv[0];
|
2010-08-05 10:22:55 +02:00
|
|
|
const char *optarg;
|
|
|
|
int argcount;
|
2008-07-08 15:19:33 +02:00
|
|
|
|
|
|
|
/* pseudo revision arguments */
|
|
|
|
if (!strcmp(arg, "--all") || !strcmp(arg, "--branches") ||
|
|
|
|
!strcmp(arg, "--tags") || !strcmp(arg, "--remotes") ||
|
|
|
|
!strcmp(arg, "--reflog") || !strcmp(arg, "--not") ||
|
2009-10-27 19:28:07 +01:00
|
|
|
!strcmp(arg, "--no-walk") || !strcmp(arg, "--do-walk") ||
|
2011-04-21 12:48:24 +02:00
|
|
|
!strcmp(arg, "--bisect") || !prefixcmp(arg, "--glob=") ||
|
|
|
|
!prefixcmp(arg, "--branches=") || !prefixcmp(arg, "--tags=") ||
|
teach log --no-walk=unsorted, which avoids sorting
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result
(unless the two revisions share the commit date, in which case they
will retain the order given on the command line). As the commit that
introduced --no-walk (8e64006 (Teach revision machinery about
--no-walk, 2007-07-24)) points out, the sorting is intentional, to
allow things like
git log --abbrev-commit --pretty=oneline --decorate --all --no-walk
to show all refs in order by commit date.
But there are also other cases where the sorting is not wanted, such
as
<command producing revisions in order> |
git log --oneline --no-walk --stdin
To accomodate both cases, leave the decision of whether or not to sort
up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
to 'sorted' for backward-compatibility reasons.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-29 08:15:54 +02:00
|
|
|
!prefixcmp(arg, "--remotes=") || !prefixcmp(arg, "--no-walk="))
|
2008-07-08 15:19:33 +02:00
|
|
|
{
|
|
|
|
unkv[(*unkc)++] = arg;
|
Allow "non-option" revision options in parse_option-enabled commands
Commands which use parse_options() but also call setup_revisions()
must do their parsing in a two step process:
1. first, they parse all options. Anything unknown goes to
parse_revision_opt() (which calls handle_revision_opt), which
may claim the option or say "I don't recognize this"
2. the non-option remainder goes to setup_revisions() to
actually get turned into revisions
Some revision options are "non-options" in that they must be
parsed in order with their revision counterparts in
setup_revisions(). For example, "--all" functions as a
pseudo-option expanding to all refs, and "--no-walk" affects refs
after it on the command line, but not before. The revision option
parser in step 1 recognizes such options and sets them aside for
later parsing by setup_revisions().
However, the return value used from handle_revision_opt indicated
"I didn't recognize this", which was wrong. It did, and it took
appropriate action (even though that action was just deferring it
for later parsing). Thus it should return "yes, I recognized
this."
Previously, these pseudo-options generated an error when used with
parse_options parsers (currently just blame and shortlog). With
this patch, they should work fine, enabling things like "git
shortlog --all".
Signed-off-by: Jeff King <peff@peff.net>
Acked-By: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 12:22:23 +02:00
|
|
|
return 1;
|
2008-07-08 15:19:33 +02:00
|
|
|
}
|
|
|
|
|
2010-08-05 10:22:55 +02:00
|
|
|
if ((argcount = parse_long_opt("max-count", argv, &optarg))) {
|
|
|
|
revs->max_count = atoi(optarg);
|
2010-06-01 10:35:49 +02:00
|
|
|
revs->no_walk = 0;
|
2010-08-05 10:22:55 +02:00
|
|
|
return argcount;
|
|
|
|
} else if ((argcount = parse_long_opt("skip", argv, &optarg))) {
|
|
|
|
revs->skip_count = atoi(optarg);
|
|
|
|
return argcount;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if ((*arg == '-') && isdigit(arg[1])) {
|
|
|
|
/* accept -<digit>, like traditional "head" */
|
|
|
|
revs->max_count = atoi(arg + 1);
|
2010-06-01 10:35:49 +02:00
|
|
|
revs->no_walk = 0;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "-n")) {
|
|
|
|
if (argc <= 1)
|
|
|
|
return error("-n requires an argument");
|
|
|
|
revs->max_count = atoi(argv[1]);
|
2010-06-01 10:35:49 +02:00
|
|
|
revs->no_walk = 0;
|
2008-07-08 15:19:33 +02:00
|
|
|
return 2;
|
|
|
|
} else if (!prefixcmp(arg, "-n")) {
|
|
|
|
revs->max_count = atoi(arg + 2);
|
2010-06-01 10:35:49 +02:00
|
|
|
revs->no_walk = 0;
|
2010-08-05 10:22:55 +02:00
|
|
|
} else if ((argcount = parse_long_opt("max-age", argv, &optarg))) {
|
|
|
|
revs->max_age = atoi(optarg);
|
|
|
|
return argcount;
|
|
|
|
} else if ((argcount = parse_long_opt("since", argv, &optarg))) {
|
|
|
|
revs->max_age = approxidate(optarg);
|
|
|
|
return argcount;
|
|
|
|
} else if ((argcount = parse_long_opt("after", argv, &optarg))) {
|
|
|
|
revs->max_age = approxidate(optarg);
|
|
|
|
return argcount;
|
|
|
|
} else if ((argcount = parse_long_opt("min-age", argv, &optarg))) {
|
|
|
|
revs->min_age = atoi(optarg);
|
|
|
|
return argcount;
|
|
|
|
} else if ((argcount = parse_long_opt("before", argv, &optarg))) {
|
|
|
|
revs->min_age = approxidate(optarg);
|
|
|
|
return argcount;
|
|
|
|
} else if ((argcount = parse_long_opt("until", argv, &optarg))) {
|
|
|
|
revs->min_age = approxidate(optarg);
|
|
|
|
return argcount;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--first-parent")) {
|
|
|
|
revs->first_parent_only = 1;
|
revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 22:48:39 +02:00
|
|
|
} else if (!strcmp(arg, "--ancestry-path")) {
|
|
|
|
revs->ancestry_path = 1;
|
2010-06-04 01:17:37 +02:00
|
|
|
revs->simplify_history = 0;
|
revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 22:48:39 +02:00
|
|
|
revs->limited = 1;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "-g") || !strcmp(arg, "--walk-reflogs")) {
|
|
|
|
init_reflog_walk(&revs->reflog_info);
|
|
|
|
} else if (!strcmp(arg, "--default")) {
|
|
|
|
if (argc <= 1)
|
|
|
|
return error("bad --default argument");
|
|
|
|
revs->def = argv[1];
|
|
|
|
return 2;
|
|
|
|
} else if (!strcmp(arg, "--merge")) {
|
|
|
|
revs->show_merge = 1;
|
|
|
|
} else if (!strcmp(arg, "--topo-order")) {
|
|
|
|
revs->lifo = 1;
|
|
|
|
revs->topo_order = 1;
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
} else if (!strcmp(arg, "--simplify-merges")) {
|
|
|
|
revs->simplify_merges = 1;
|
2012-06-08 23:47:08 +02:00
|
|
|
revs->topo_order = 1;
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
revs->rewrite_parents = 1;
|
|
|
|
revs->simplify_history = 0;
|
|
|
|
revs->limited = 1;
|
2008-11-03 20:25:46 +01:00
|
|
|
} else if (!strcmp(arg, "--simplify-by-decoration")) {
|
|
|
|
revs->simplify_merges = 1;
|
2012-06-08 23:47:08 +02:00
|
|
|
revs->topo_order = 1;
|
2008-11-03 20:25:46 +01:00
|
|
|
revs->rewrite_parents = 1;
|
|
|
|
revs->simplify_history = 0;
|
|
|
|
revs->simplify_by_decoration = 1;
|
|
|
|
revs->limited = 1;
|
|
|
|
revs->prune = 1;
|
2009-08-15 16:23:12 +02:00
|
|
|
load_ref_decorations(DECORATE_SHORT_REFS);
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--date-order")) {
|
|
|
|
revs->lifo = 0;
|
|
|
|
revs->topo_order = 1;
|
|
|
|
} else if (!prefixcmp(arg, "--early-output")) {
|
|
|
|
int count = 100;
|
|
|
|
switch (arg[14]) {
|
|
|
|
case '=':
|
|
|
|
count = atoi(arg+15);
|
|
|
|
/* Fallthrough */
|
|
|
|
case 0:
|
|
|
|
revs->topo_order = 1;
|
|
|
|
revs->early_output = count;
|
|
|
|
}
|
|
|
|
} else if (!strcmp(arg, "--parents")) {
|
|
|
|
revs->rewrite_parents = 1;
|
|
|
|
revs->print_parents = 1;
|
|
|
|
} else if (!strcmp(arg, "--dense")) {
|
|
|
|
revs->dense = 1;
|
|
|
|
} else if (!strcmp(arg, "--sparse")) {
|
|
|
|
revs->dense = 0;
|
|
|
|
} else if (!strcmp(arg, "--show-all")) {
|
|
|
|
revs->show_all = 1;
|
|
|
|
} else if (!strcmp(arg, "--remove-empty")) {
|
|
|
|
revs->remove_empty_trees = 1;
|
2009-06-29 19:28:25 +02:00
|
|
|
} else if (!strcmp(arg, "--merges")) {
|
2011-03-21 11:14:06 +01:00
|
|
|
revs->min_parents = 2;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--no-merges")) {
|
2011-03-21 11:14:06 +01:00
|
|
|
revs->max_parents = 1;
|
|
|
|
} else if (!prefixcmp(arg, "--min-parents=")) {
|
|
|
|
revs->min_parents = atoi(arg+14);
|
|
|
|
} else if (!prefixcmp(arg, "--no-min-parents")) {
|
|
|
|
revs->min_parents = 0;
|
|
|
|
} else if (!prefixcmp(arg, "--max-parents=")) {
|
|
|
|
revs->max_parents = atoi(arg+14);
|
|
|
|
} else if (!prefixcmp(arg, "--no-max-parents")) {
|
|
|
|
revs->max_parents = -1;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--boundary")) {
|
|
|
|
revs->boundary = 1;
|
|
|
|
} else if (!strcmp(arg, "--left-right")) {
|
|
|
|
revs->left_right = 1;
|
2011-02-21 17:09:11 +01:00
|
|
|
} else if (!strcmp(arg, "--left-only")) {
|
2011-02-22 01:58:37 +01:00
|
|
|
if (revs->right_only)
|
2011-03-07 13:31:42 +01:00
|
|
|
die("--left-only is incompatible with --right-only"
|
|
|
|
" or --cherry");
|
2011-02-21 17:09:11 +01:00
|
|
|
revs->left_only = 1;
|
|
|
|
} else if (!strcmp(arg, "--right-only")) {
|
2011-02-22 01:58:37 +01:00
|
|
|
if (revs->left_only)
|
|
|
|
die("--right-only is incompatible with --left-only");
|
2011-02-21 17:09:11 +01:00
|
|
|
revs->right_only = 1;
|
2011-03-07 13:31:42 +01:00
|
|
|
} else if (!strcmp(arg, "--cherry")) {
|
|
|
|
if (revs->left_only)
|
|
|
|
die("--cherry is incompatible with --left-only");
|
|
|
|
revs->cherry_mark = 1;
|
|
|
|
revs->right_only = 1;
|
2011-03-21 11:14:06 +01:00
|
|
|
revs->max_parents = 1;
|
2011-03-07 13:31:42 +01:00
|
|
|
revs->limited = 1;
|
2010-06-10 13:47:23 +02:00
|
|
|
} else if (!strcmp(arg, "--count")) {
|
|
|
|
revs->count = 1;
|
2011-03-07 13:31:40 +01:00
|
|
|
} else if (!strcmp(arg, "--cherry-mark")) {
|
|
|
|
if (revs->cherry_pick)
|
|
|
|
die("--cherry-mark is incompatible with --cherry-pick");
|
|
|
|
revs->cherry_mark = 1;
|
|
|
|
revs->limited = 1; /* needs limit_list() */
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--cherry-pick")) {
|
2011-03-07 13:31:40 +01:00
|
|
|
if (revs->cherry_mark)
|
|
|
|
die("--cherry-pick is incompatible with --cherry-mark");
|
2008-07-08 15:19:33 +02:00
|
|
|
revs->cherry_pick = 1;
|
|
|
|
revs->limited = 1;
|
|
|
|
} else if (!strcmp(arg, "--objects")) {
|
|
|
|
revs->tag_objects = 1;
|
|
|
|
revs->tree_objects = 1;
|
|
|
|
revs->blob_objects = 1;
|
|
|
|
} else if (!strcmp(arg, "--objects-edge")) {
|
|
|
|
revs->tag_objects = 1;
|
|
|
|
revs->tree_objects = 1;
|
|
|
|
revs->blob_objects = 1;
|
|
|
|
revs->edge_hint = 1;
|
2011-09-02 00:43:34 +02:00
|
|
|
} else if (!strcmp(arg, "--verify-objects")) {
|
|
|
|
revs->tag_objects = 1;
|
|
|
|
revs->tree_objects = 1;
|
|
|
|
revs->blob_objects = 1;
|
|
|
|
revs->verify_objects = 1;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--unpacked")) {
|
|
|
|
revs->unpacked = 1;
|
2009-02-28 09:00:21 +01:00
|
|
|
} else if (!prefixcmp(arg, "--unpacked=")) {
|
|
|
|
die("--unpacked=<packfile> no longer supported.");
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "-r")) {
|
|
|
|
revs->diff = 1;
|
|
|
|
DIFF_OPT_SET(&revs->diffopt, RECURSIVE);
|
|
|
|
} else if (!strcmp(arg, "-t")) {
|
|
|
|
revs->diff = 1;
|
|
|
|
DIFF_OPT_SET(&revs->diffopt, RECURSIVE);
|
|
|
|
DIFF_OPT_SET(&revs->diffopt, TREE_IN_RECURSIVE);
|
|
|
|
} else if (!strcmp(arg, "-m")) {
|
|
|
|
revs->ignore_merges = 0;
|
|
|
|
} else if (!strcmp(arg, "-c")) {
|
|
|
|
revs->diff = 1;
|
|
|
|
revs->dense_combined_merges = 0;
|
|
|
|
revs->combine_merges = 1;
|
|
|
|
} else if (!strcmp(arg, "--cc")) {
|
|
|
|
revs->diff = 1;
|
|
|
|
revs->dense_combined_merges = 1;
|
|
|
|
revs->combine_merges = 1;
|
|
|
|
} else if (!strcmp(arg, "-v")) {
|
|
|
|
revs->verbose_header = 1;
|
|
|
|
} else if (!strcmp(arg, "--pretty")) {
|
|
|
|
revs->verbose_header = 1;
|
2010-01-20 22:59:36 +01:00
|
|
|
revs->pretty_given = 1;
|
2008-07-08 15:19:33 +02:00
|
|
|
get_commit_format(arg+8, revs);
|
2009-02-24 10:59:14 +01:00
|
|
|
} else if (!prefixcmp(arg, "--pretty=") || !prefixcmp(arg, "--format=")) {
|
2010-08-05 10:22:55 +02:00
|
|
|
/*
|
|
|
|
* Detached form ("--pretty X" as opposed to "--pretty=X")
|
|
|
|
* not allowed, since the argument is optional.
|
|
|
|
*/
|
2008-07-08 15:19:33 +02:00
|
|
|
revs->verbose_header = 1;
|
2010-01-20 22:59:36 +01:00
|
|
|
revs->pretty_given = 1;
|
2008-07-08 15:19:33 +02:00
|
|
|
get_commit_format(arg+9, revs);
|
2011-03-29 22:57:47 +02:00
|
|
|
} else if (!strcmp(arg, "--show-notes") || !strcmp(arg, "--notes")) {
|
2010-01-20 22:59:36 +01:00
|
|
|
revs->show_notes = 1;
|
|
|
|
revs->show_notes_given = 1;
|
2011-03-29 22:57:27 +02:00
|
|
|
revs->notes_opt.use_default_notes = 1;
|
2011-10-19 00:53:23 +02:00
|
|
|
} else if (!strcmp(arg, "--show-signature")) {
|
|
|
|
revs->show_signature = 1;
|
2011-03-29 22:57:47 +02:00
|
|
|
} else if (!prefixcmp(arg, "--show-notes=") ||
|
|
|
|
!prefixcmp(arg, "--notes=")) {
|
2010-03-12 18:04:26 +01:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
revs->show_notes = 1;
|
|
|
|
revs->show_notes_given = 1;
|
2011-03-29 22:57:47 +02:00
|
|
|
if (!prefixcmp(arg, "--show-notes")) {
|
|
|
|
if (revs->notes_opt.use_default_notes < 0)
|
|
|
|
revs->notes_opt.use_default_notes = 1;
|
|
|
|
strbuf_addstr(&buf, arg+13);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
strbuf_addstr(&buf, arg+8);
|
2011-03-29 22:56:04 +02:00
|
|
|
expand_notes_ref(&buf);
|
2011-03-29 22:56:53 +02:00
|
|
|
string_list_append(&revs->notes_opt.extra_notes_refs,
|
2010-06-26 01:41:38 +02:00
|
|
|
strbuf_detach(&buf, NULL));
|
2010-01-20 22:59:36 +01:00
|
|
|
} else if (!strcmp(arg, "--no-notes")) {
|
|
|
|
revs->show_notes = 0;
|
|
|
|
revs->show_notes_given = 1;
|
2011-03-29 22:59:42 +02:00
|
|
|
revs->notes_opt.use_default_notes = -1;
|
|
|
|
/* we have been strdup'ing ourselves, so trick
|
|
|
|
* string_list into free()ing strings */
|
|
|
|
revs->notes_opt.extra_notes_refs.strdup_strings = 1;
|
|
|
|
string_list_clear(&revs->notes_opt.extra_notes_refs, 0);
|
|
|
|
revs->notes_opt.extra_notes_refs.strdup_strings = 0;
|
2010-03-12 18:04:26 +01:00
|
|
|
} else if (!strcmp(arg, "--standard-notes")) {
|
|
|
|
revs->show_notes_given = 1;
|
2011-03-29 22:57:27 +02:00
|
|
|
revs->notes_opt.use_default_notes = 1;
|
2010-03-12 18:04:26 +01:00
|
|
|
} else if (!strcmp(arg, "--no-standard-notes")) {
|
2011-03-29 22:57:27 +02:00
|
|
|
revs->notes_opt.use_default_notes = 0;
|
2009-02-24 10:59:16 +01:00
|
|
|
} else if (!strcmp(arg, "--oneline")) {
|
|
|
|
revs->verbose_header = 1;
|
|
|
|
get_commit_format("oneline", revs);
|
2010-01-21 23:57:41 +01:00
|
|
|
revs->pretty_given = 1;
|
2009-02-24 10:59:16 +01:00
|
|
|
revs->abbrev_commit = 1;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--graph")) {
|
|
|
|
revs->topo_order = 1;
|
|
|
|
revs->rewrite_parents = 1;
|
|
|
|
revs->graph = graph_init(revs);
|
|
|
|
} else if (!strcmp(arg, "--root")) {
|
|
|
|
revs->show_root_diff = 1;
|
|
|
|
} else if (!strcmp(arg, "--no-commit-id")) {
|
|
|
|
revs->no_commit_id = 1;
|
|
|
|
} else if (!strcmp(arg, "--always")) {
|
|
|
|
revs->always_show_header = 1;
|
|
|
|
} else if (!strcmp(arg, "--no-abbrev")) {
|
|
|
|
revs->abbrev = 0;
|
|
|
|
} else if (!strcmp(arg, "--abbrev")) {
|
|
|
|
revs->abbrev = DEFAULT_ABBREV;
|
|
|
|
} else if (!prefixcmp(arg, "--abbrev=")) {
|
|
|
|
revs->abbrev = strtoul(arg + 9, NULL, 10);
|
|
|
|
if (revs->abbrev < MINIMUM_ABBREV)
|
|
|
|
revs->abbrev = MINIMUM_ABBREV;
|
|
|
|
else if (revs->abbrev > 40)
|
|
|
|
revs->abbrev = 40;
|
|
|
|
} else if (!strcmp(arg, "--abbrev-commit")) {
|
|
|
|
revs->abbrev_commit = 1;
|
2011-05-18 19:56:04 +02:00
|
|
|
revs->abbrev_commit_given = 1;
|
|
|
|
} else if (!strcmp(arg, "--no-abbrev-commit")) {
|
|
|
|
revs->abbrev_commit = 0;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--full-diff")) {
|
|
|
|
revs->diff = 1;
|
|
|
|
revs->full_diff = 1;
|
|
|
|
} else if (!strcmp(arg, "--full-history")) {
|
|
|
|
revs->simplify_history = 0;
|
|
|
|
} else if (!strcmp(arg, "--relative-date")) {
|
|
|
|
revs->date_mode = DATE_RELATIVE;
|
2009-09-24 10:28:15 +02:00
|
|
|
revs->date_mode_explicit = 1;
|
2010-08-05 10:22:55 +02:00
|
|
|
} else if ((argcount = parse_long_opt("date", argv, &optarg))) {
|
|
|
|
revs->date_mode = parse_date_format(optarg);
|
2009-09-24 10:28:15 +02:00
|
|
|
revs->date_mode_explicit = 1;
|
2010-08-05 10:22:55 +02:00
|
|
|
return argcount;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--log-size")) {
|
|
|
|
revs->show_log_size = 1;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Grepping the commit log
|
|
|
|
*/
|
2010-08-05 10:22:55 +02:00
|
|
|
else if ((argcount = parse_long_opt("author", argv, &optarg))) {
|
|
|
|
add_header_grep(revs, GREP_HEADER_AUTHOR, optarg);
|
|
|
|
return argcount;
|
|
|
|
} else if ((argcount = parse_long_opt("committer", argv, &optarg))) {
|
|
|
|
add_header_grep(revs, GREP_HEADER_COMMITTER, optarg);
|
|
|
|
return argcount;
|
2012-09-29 06:41:28 +02:00
|
|
|
} else if ((argcount = parse_long_opt("grep-reflog", argv, &optarg))) {
|
|
|
|
add_header_grep(revs, GREP_HEADER_REFLOG, optarg);
|
|
|
|
return argcount;
|
2010-08-05 10:22:55 +02:00
|
|
|
} else if ((argcount = parse_long_opt("grep", argv, &optarg))) {
|
|
|
|
add_message_grep(revs, optarg);
|
|
|
|
return argcount;
|
2012-09-13 23:21:44 +02:00
|
|
|
} else if (!strcmp(arg, "--grep-debug")) {
|
|
|
|
revs->grep_filter.debug = 1;
|
2012-10-04 00:01:34 +02:00
|
|
|
} else if (!strcmp(arg, "--basic-regexp")) {
|
|
|
|
grep_set_pattern_type_option(GREP_PATTERN_TYPE_BRE, &revs->grep_filter);
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--extended-regexp") || !strcmp(arg, "-E")) {
|
2012-10-03 23:50:51 +02:00
|
|
|
grep_set_pattern_type_option(GREP_PATTERN_TYPE_ERE, &revs->grep_filter);
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--regexp-ignore-case") || !strcmp(arg, "-i")) {
|
2008-08-25 08:15:05 +02:00
|
|
|
revs->grep_filter.regflags |= REG_ICASE;
|
2012-02-21 10:02:46 +01:00
|
|
|
DIFF_OPT_SET(&revs->diffopt, PICKAXE_IGNORE_CASE);
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--fixed-strings") || !strcmp(arg, "-F")) {
|
2012-10-03 23:50:51 +02:00
|
|
|
grep_set_pattern_type_option(GREP_PATTERN_TYPE_FIXED, &revs->grep_filter);
|
2012-10-04 00:01:34 +02:00
|
|
|
} else if (!strcmp(arg, "--perl-regexp")) {
|
|
|
|
grep_set_pattern_type_option(GREP_PATTERN_TYPE_PCRE, &revs->grep_filter);
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--all-match")) {
|
2008-08-25 08:15:05 +02:00
|
|
|
revs->grep_filter.all_match = 1;
|
2010-08-05 10:22:55 +02:00
|
|
|
} else if ((argcount = parse_long_opt("encoding", argv, &optarg))) {
|
|
|
|
if (strcmp(optarg, "none"))
|
|
|
|
git_log_output_encoding = xstrdup(optarg);
|
2008-07-08 15:19:33 +02:00
|
|
|
else
|
|
|
|
git_log_output_encoding = "";
|
2010-08-05 10:22:55 +02:00
|
|
|
return argcount;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else if (!strcmp(arg, "--reverse")) {
|
|
|
|
revs->reverse ^= 1;
|
|
|
|
} else if (!strcmp(arg, "--children")) {
|
|
|
|
revs->children.name = "children";
|
|
|
|
revs->limited = 1;
|
2011-05-19 03:08:09 +02:00
|
|
|
} else if (!strcmp(arg, "--ignore-missing")) {
|
|
|
|
revs->ignore_missing = 1;
|
2008-07-08 15:19:33 +02:00
|
|
|
} else {
|
|
|
|
int opts = diff_opt_parse(&revs->diffopt, argv, argc);
|
|
|
|
if (!opts)
|
|
|
|
unkv[(*unkc)++] = arg;
|
|
|
|
return opts;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2008-07-09 23:38:34 +02:00
|
|
|
void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
|
|
|
|
const struct option *options,
|
|
|
|
const char * const usagestr[])
|
|
|
|
{
|
|
|
|
int n = handle_revision_opt(revs, ctx->argc, ctx->argv,
|
|
|
|
&ctx->cpidx, ctx->out);
|
|
|
|
if (n <= 0) {
|
|
|
|
error("unknown option `%s'", ctx->argv[0]);
|
|
|
|
usage_with_options(usagestr, options);
|
|
|
|
}
|
|
|
|
ctx->argv += n;
|
|
|
|
ctx->argc -= n;
|
|
|
|
}
|
|
|
|
|
2010-07-07 15:39:12 +02:00
|
|
|
static int for_each_bad_bisect_ref(const char *submodule, each_ref_fn fn, void *cb_data)
|
2009-10-27 19:28:07 +01:00
|
|
|
{
|
2010-07-07 15:39:12 +02:00
|
|
|
return for_each_ref_in_submodule(submodule, "refs/bisect/bad", fn, cb_data);
|
2009-10-27 19:28:07 +01:00
|
|
|
}
|
|
|
|
|
2010-07-07 15:39:12 +02:00
|
|
|
static int for_each_good_bisect_ref(const char *submodule, each_ref_fn fn, void *cb_data)
|
2009-10-27 19:28:07 +01:00
|
|
|
{
|
2010-07-07 15:39:12 +02:00
|
|
|
return for_each_ref_in_submodule(submodule, "refs/bisect/good", fn, cb_data);
|
2009-10-27 19:28:07 +01:00
|
|
|
}
|
|
|
|
|
2011-04-21 12:45:07 +02:00
|
|
|
static int handle_revision_pseudo_opt(const char *submodule,
|
|
|
|
struct rev_info *revs,
|
|
|
|
int argc, const char **argv, int *flags)
|
|
|
|
{
|
|
|
|
const char *arg = argv[0];
|
|
|
|
const char *optarg;
|
|
|
|
int argcount;
|
|
|
|
|
2011-04-21 12:48:24 +02:00
|
|
|
/*
|
|
|
|
* NOTE!
|
|
|
|
*
|
|
|
|
* Commands like "git shortlog" will not accept the options below
|
|
|
|
* unless parse_revision_opt queues them (as opposed to erroring
|
|
|
|
* out).
|
|
|
|
*
|
|
|
|
* When implementing your new pseudo-option, remember to
|
|
|
|
* register it in the list at the top of handle_revision_opt.
|
|
|
|
*/
|
2011-04-21 12:45:07 +02:00
|
|
|
if (!strcmp(arg, "--all")) {
|
|
|
|
handle_refs(submodule, revs, *flags, for_each_ref_submodule);
|
|
|
|
handle_refs(submodule, revs, *flags, head_ref_submodule);
|
|
|
|
} else if (!strcmp(arg, "--branches")) {
|
|
|
|
handle_refs(submodule, revs, *flags, for_each_branch_ref_submodule);
|
|
|
|
} else if (!strcmp(arg, "--bisect")) {
|
|
|
|
handle_refs(submodule, revs, *flags, for_each_bad_bisect_ref);
|
|
|
|
handle_refs(submodule, revs, *flags ^ UNINTERESTING, for_each_good_bisect_ref);
|
|
|
|
revs->bisect = 1;
|
|
|
|
} else if (!strcmp(arg, "--tags")) {
|
|
|
|
handle_refs(submodule, revs, *flags, for_each_tag_ref_submodule);
|
|
|
|
} else if (!strcmp(arg, "--remotes")) {
|
|
|
|
handle_refs(submodule, revs, *flags, for_each_remote_ref_submodule);
|
|
|
|
} else if ((argcount = parse_long_opt("glob", argv, &optarg))) {
|
|
|
|
struct all_refs_cb cb;
|
|
|
|
init_all_refs_cb(&cb, revs, *flags);
|
|
|
|
for_each_glob_ref(handle_one_ref, optarg, &cb);
|
|
|
|
return argcount;
|
|
|
|
} else if (!prefixcmp(arg, "--branches=")) {
|
|
|
|
struct all_refs_cb cb;
|
|
|
|
init_all_refs_cb(&cb, revs, *flags);
|
|
|
|
for_each_glob_ref_in(handle_one_ref, arg + 11, "refs/heads/", &cb);
|
|
|
|
} else if (!prefixcmp(arg, "--tags=")) {
|
|
|
|
struct all_refs_cb cb;
|
|
|
|
init_all_refs_cb(&cb, revs, *flags);
|
|
|
|
for_each_glob_ref_in(handle_one_ref, arg + 7, "refs/tags/", &cb);
|
|
|
|
} else if (!prefixcmp(arg, "--remotes=")) {
|
|
|
|
struct all_refs_cb cb;
|
|
|
|
init_all_refs_cb(&cb, revs, *flags);
|
|
|
|
for_each_glob_ref_in(handle_one_ref, arg + 10, "refs/remotes/", &cb);
|
|
|
|
} else if (!strcmp(arg, "--reflog")) {
|
|
|
|
handle_reflog(revs, *flags);
|
|
|
|
} else if (!strcmp(arg, "--not")) {
|
|
|
|
*flags ^= UNINTERESTING;
|
|
|
|
} else if (!strcmp(arg, "--no-walk")) {
|
teach log --no-walk=unsorted, which avoids sorting
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result
(unless the two revisions share the commit date, in which case they
will retain the order given on the command line). As the commit that
introduced --no-walk (8e64006 (Teach revision machinery about
--no-walk, 2007-07-24)) points out, the sorting is intentional, to
allow things like
git log --abbrev-commit --pretty=oneline --decorate --all --no-walk
to show all refs in order by commit date.
But there are also other cases where the sorting is not wanted, such
as
<command producing revisions in order> |
git log --oneline --no-walk --stdin
To accomodate both cases, leave the decision of whether or not to sort
up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
to 'sorted' for backward-compatibility reasons.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-29 08:15:54 +02:00
|
|
|
revs->no_walk = REVISION_WALK_NO_WALK_SORTED;
|
|
|
|
} else if (!prefixcmp(arg, "--no-walk=")) {
|
|
|
|
/*
|
|
|
|
* Detached form ("--no-walk X" as opposed to "--no-walk=X")
|
|
|
|
* not allowed, since the argument is optional.
|
|
|
|
*/
|
|
|
|
if (!strcmp(arg + 10, "sorted"))
|
|
|
|
revs->no_walk = REVISION_WALK_NO_WALK_SORTED;
|
|
|
|
else if (!strcmp(arg + 10, "unsorted"))
|
|
|
|
revs->no_walk = REVISION_WALK_NO_WALK_UNSORTED;
|
|
|
|
else
|
|
|
|
return error("invalid argument to --no-walk");
|
2011-04-21 12:45:07 +02:00
|
|
|
} else if (!strcmp(arg, "--do-walk")) {
|
|
|
|
revs->no_walk = 0;
|
|
|
|
} else {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
*/
|
2010-03-09 07:58:09 +01:00
|
|
|
int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct setup_revision_opt *opt)
|
2006-02-26 01:19:46 +01:00
|
|
|
{
|
2012-07-02 21:33:52 +02:00
|
|
|
int i, flags, left, seen_dashdash, read_from_stdin, got_rev_arg = 0, revarg_opt;
|
2011-05-11 23:01:19 +02:00
|
|
|
struct cmdline_pathspec prune_data;
|
2010-07-07 15:39:12 +02:00
|
|
|
const char *submodule = NULL;
|
|
|
|
|
2011-05-11 23:01:19 +02:00
|
|
|
memset(&prune_data, 0, sizeof(prune_data));
|
2010-07-07 15:39:12 +02:00
|
|
|
if (opt)
|
|
|
|
submodule = opt->submodule;
|
2006-02-26 01:19:46 +01:00
|
|
|
|
|
|
|
/* First, search for "--" */
|
2012-04-14 21:04:48 +02:00
|
|
|
if (opt && opt->assume_dashdash) {
|
2006-02-26 01:19:46 +01:00
|
|
|
seen_dashdash = 1;
|
2012-04-14 21:04:48 +02:00
|
|
|
} else {
|
|
|
|
seen_dashdash = 0;
|
|
|
|
for (i = 1; i < argc; i++) {
|
|
|
|
const char *arg = argv[i];
|
|
|
|
if (strcmp(arg, "--"))
|
|
|
|
continue;
|
|
|
|
argv[i] = NULL;
|
|
|
|
argc = i;
|
|
|
|
if (argv[i + 1])
|
|
|
|
append_prune_data(&prune_data, argv + i + 1);
|
|
|
|
seen_dashdash = 1;
|
|
|
|
break;
|
|
|
|
}
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
|
|
|
|
2008-07-08 15:19:33 +02:00
|
|
|
/* Second, deal with arguments and options */
|
|
|
|
flags = 0;
|
2012-07-02 21:43:05 +02:00
|
|
|
revarg_opt = opt ? opt->revarg_opt : 0;
|
|
|
|
if (seen_dashdash)
|
|
|
|
revarg_opt |= REVARG_CANNOT_BE_FILENAME;
|
2009-11-03 15:59:18 +01:00
|
|
|
read_from_stdin = 0;
|
2008-07-08 15:19:33 +02:00
|
|
|
for (left = i = 1; i < argc; i++) {
|
2006-02-26 01:19:46 +01:00
|
|
|
const char *arg = argv[i];
|
|
|
|
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;
|
2008-07-08 15:19:33 +02:00
|
|
|
|
2011-04-21 12:45:07 +02:00
|
|
|
opts = handle_revision_pseudo_opt(submodule,
|
|
|
|
revs, argc - i, argv + i,
|
|
|
|
&flags);
|
|
|
|
if (opts > 0) {
|
|
|
|
i += opts - 1;
|
2007-07-24 01:38:40 +02:00
|
|
|
continue;
|
|
|
|
}
|
2011-04-21 12:45:07 +02:00
|
|
|
|
2009-11-03 15:59:18 +01:00
|
|
|
if (!strcmp(arg, "--stdin")) {
|
|
|
|
if (revs->disable_stdin) {
|
|
|
|
argv[left++] = arg;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (read_from_stdin++)
|
|
|
|
die("--stdin given twice?");
|
2009-11-20 11:50:21 +01:00
|
|
|
read_revisions_from_stdin(revs, &prune_data);
|
2009-11-03 15:59:18 +01:00
|
|
|
continue;
|
|
|
|
}
|
2006-09-20 22:21:56 +02:00
|
|
|
|
2008-07-08 15:19:33 +02:00
|
|
|
opts = handle_revision_opt(revs, argc - i, argv + i, &left, argv);
|
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 (opts > 0) {
|
|
|
|
i += opts - 1;
|
|
|
|
continue;
|
|
|
|
}
|
2008-07-08 15:19:33 +02:00
|
|
|
if (opts < 0)
|
|
|
|
exit(128);
|
2006-02-26 01:19:46 +01:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2012-07-02 21:33:52 +02:00
|
|
|
|
|
|
|
if (handle_revision_arg(arg, revs, flags, revarg_opt)) {
|
2006-09-06 06:28:36 +02:00
|
|
|
int j;
|
|
|
|
if (seen_dashdash || *arg == '^')
|
2006-02-26 01:19:46 +01:00
|
|
|
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++)
|
2012-06-18 20:18:21 +02:00
|
|
|
verify_filename(revs->prefix, argv[j], j == i);
|
2006-04-26 19:15:54 +02:00
|
|
|
|
2009-11-20 11:50:21 +01:00
|
|
|
append_prune_data(&prune_data, argv + i);
|
2006-02-26 01:19:46 +01:00
|
|
|
break;
|
|
|
|
}
|
2010-03-13 23:47:05 +01:00
|
|
|
else
|
|
|
|
got_rev_arg = 1;
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
2006-09-06 06:28:36 +02:00
|
|
|
|
2011-05-11 23:01:19 +02:00
|
|
|
if (prune_data.nr) {
|
2011-05-12 00:23:25 +02:00
|
|
|
/*
|
|
|
|
* If we need to introduce the magic "a lone ':' means no
|
|
|
|
* pathspec whatsoever", here is the place to do so.
|
|
|
|
*
|
|
|
|
* if (prune_data.nr == 1 && !strcmp(prune_data[0], ":")) {
|
|
|
|
* prune_data.nr = 0;
|
|
|
|
* prune_data.alloc = 0;
|
|
|
|
* free(prune_data.path);
|
|
|
|
* prune_data.path = NULL;
|
|
|
|
* } else {
|
|
|
|
* terminate prune_data.alloc with NULL and
|
|
|
|
* call init_pathspec() to set revs->prune_data here.
|
|
|
|
* }
|
|
|
|
*/
|
2011-05-11 23:01:19 +02:00
|
|
|
ALLOC_GROW(prune_data.path, prune_data.nr+1, prune_data.alloc);
|
|
|
|
prune_data.path[prune_data.nr++] = NULL;
|
2011-05-12 00:05:01 +02:00
|
|
|
init_pathspec(&revs->prune_data,
|
|
|
|
get_pathspec(revs->prefix, prune_data.path));
|
2011-05-11 23:01:19 +02:00
|
|
|
}
|
2009-11-20 11:33:28 +01:00
|
|
|
|
2008-07-08 15:19:33 +02:00
|
|
|
if (revs->def == NULL)
|
2010-03-09 07:58:09 +01:00
|
|
|
revs->def = opt ? opt->def : NULL;
|
2010-03-09 08:27:25 +01:00
|
|
|
if (opt && opt->tweak)
|
|
|
|
opt->tweak(revs, opt);
|
2008-07-08 15:19:33 +02:00
|
|
|
if (revs->show_merge)
|
2006-07-03 11:59:32 +02:00
|
|
|
prepare_show_merge(revs);
|
2010-03-13 23:47:05 +01:00
|
|
|
if (revs->def && !revs->pending.nr && !got_rev_arg) {
|
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;
|
2012-07-02 21:56:44 +02:00
|
|
|
struct object_context oc;
|
2012-07-02 19:32:11 +02:00
|
|
|
if (get_sha1_with_context(revs->def, 0, sha1, &oc))
|
2008-07-08 15:19:33 +02:00
|
|
|
die("bad default revision '%s'", revs->def);
|
|
|
|
object = get_reference(revs, revs->def, sha1, 0);
|
2012-07-02 21:56:44 +02:00
|
|
|
add_pending_object_with_mode(revs, object, revs->def, oc.mode);
|
2006-02-26 01:19:46 +01:00
|
|
|
}
|
2006-03-10 10:21:39 +01:00
|
|
|
|
2007-09-29 18:50:39 +02:00
|
|
|
/* Did the user ask for any diff output? Run the diff! */
|
|
|
|
if (revs->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT)
|
|
|
|
revs->diff = 1;
|
|
|
|
|
2007-12-25 12:06:47 +01:00
|
|
|
/* Pickaxe, diff-filter and rename following need diffs */
|
|
|
|
if (revs->diffopt.pickaxe ||
|
|
|
|
revs->diffopt.filter ||
|
|
|
|
DIFF_OPT_TST(&revs->diffopt, FOLLOW_RENAMES))
|
2007-09-29 18:50:39 +02:00
|
|
|
revs->diff = 1;
|
|
|
|
|
2006-10-31 03:58:03 +01:00
|
|
|
if (revs->topo_order)
|
2006-04-02 04:38:25 +02:00
|
|
|
revs->limited = 1;
|
|
|
|
|
2010-12-17 13:43:06 +01:00
|
|
|
if (revs->prune_data.nr) {
|
|
|
|
diff_tree_setup_paths(revs->prune_data.raw, &revs->pruning);
|
Finally implement "git log --follow"
Ok, I've really held off doing this too damn long, because I'm lazy, and I
was always hoping that somebody else would do it.
But no, people keep asking for it, but nobody actually did anything, so I
decided I might as well bite the bullet, and instead of telling people
they could add a "--follow" flag to "git log" to do what they want to do,
I decided that it looks like I just have to do it for them..
The code wasn't actually that complicated, in that the diffstat for this
patch literally says "70 insertions(+), 1 deletions(-)", but I will have
to admit that in order to get to this fairly simple patch, you did have to
know and understand the internal git diff generation machinery pretty
well, and had to really be able to follow how commit generation interacts
with generating patches and generating the log.
So I suspect that while I was right that it wasn't that hard, I might have
been expecting too much of random people - this patch does seem to be
firmly in the core "Linus or Junio" territory.
To make a long story short: I'm sorry for it taking so long until I just
did it.
I'm not going to guarantee that this works for everybody, but you really
can just look at the patch, and after the appropriate appreciative noises
("Ooh, aah") over how clever I am, you can then just notice that the code
itself isn't really that complicated.
All the real new code is in the new "try_to_follow_renames()" function. It
really isn't rocket science: we notice that the pathname we were looking
at went away, so we start a full tree diff and try to see if we can
instead make that pathname be a rename or a copy from some other previous
pathname. And if we can, we just continue, except we show *that*
particular diff, and ever after we use the _previous_ pathname.
One thing to look out for: the "rename detection" is considered to be a
singular event in the _linear_ "git log" output! That's what people want
to do, but I just wanted to point out that this patch is *not* carrying
around a "commit,pathname" kind of pair and it's *not* going to be able to
notice the file coming from multiple *different* files in earlier history.
IOW, if you use "git log --follow", then you get the stupid CVS/SVN kind
of "files have single identities" kind of semantics, and git log will just
pick the identity based on the normal move/copy heuristics _as_if_ the
history could be linearized.
Put another way: I think the model is broken, but given the broken model,
I think this patch does just about as well as you can do. If you have
merges with the same "file" having different filenames over the two
branches, git will just end up picking _one_ of the pathnames at the point
where the newer one goes away. It never looks at multiple pathnames in
parallel.
And if you understood all that, you probably didn't need it explained, and
if you didn't understand the above blathering, it doesn't really mtter to
you. What matters to you is that you can now do
git log -p --follow builtin-rev-list.c
and it will find the point where the old "rev-list.c" got renamed to
"builtin-rev-list.c" and show it as such.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-19 23:22:46 +02:00
|
|
|
/* Can't prune commits with rename following: the paths change.. */
|
2007-11-10 20:05:14 +01:00
|
|
|
if (!DIFF_OPT_TST(&revs->diffopt, FOLLOW_RENAMES))
|
2007-11-05 22:22:34 +01:00
|
|
|
revs->prune = 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
|
|
|
if (!revs->full_diff)
|
2010-12-17 13:43:06 +01:00
|
|
|
diff_tree_setup_paths(revs->prune_data.raw, &revs->diffopt);
|
2006-03-10 10:21:39 +01:00
|
|
|
}
|
2010-03-09 08:27:25 +01:00
|
|
|
if (revs->combine_merges)
|
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->ignore_merges = 0;
|
|
|
|
revs->diffopt.abbrev = revs->abbrev;
|
2012-08-03 14:16:24 +02:00
|
|
|
diff_setup_done(&revs->diffopt);
|
2006-03-10 10:21:39 +01:00
|
|
|
|
2012-10-10 01:40:03 +02:00
|
|
|
grep_commit_pattern_type(GREP_PATTERN_TYPE_UNSPECIFIED,
|
|
|
|
&revs->grep_filter);
|
2008-08-25 08:15:05 +02:00
|
|
|
compile_grep_patterns(&revs->grep_filter);
|
2006-09-18 02:23:20 +02:00
|
|
|
|
2007-08-20 04:33:43 +02:00
|
|
|
if (revs->reverse && revs->reflog_info)
|
|
|
|
die("cannot combine --reverse with --walk-reflogs");
|
2008-07-09 00:25:44 +02:00
|
|
|
if (revs->rewrite_parents && revs->children.name)
|
2008-04-03 11:12:06 +02:00
|
|
|
die("cannot combine --parents and --children");
|
2007-08-20 04:33:43 +02:00
|
|
|
|
2008-05-04 12:36:54 +02:00
|
|
|
/*
|
|
|
|
* Limitations on the graph functionality
|
|
|
|
*/
|
|
|
|
if (revs->reverse && revs->graph)
|
|
|
|
die("cannot combine --reverse with --graph");
|
|
|
|
|
|
|
|
if (revs->reflog_info && revs->graph)
|
|
|
|
die("cannot combine --walk-reflogs with --graph");
|
2012-09-29 20:59:52 +02:00
|
|
|
if (!revs->reflog_info && revs->grep_filter.use_reflog_filter)
|
|
|
|
die("cannot use --grep-reflog without --walk-reflogs");
|
2008-05-04 12:36:54 +02:00
|
|
|
|
2006-02-26 01:19:46 +01:00
|
|
|
return left;
|
|
|
|
}
|
2006-02-28 20:24:00 +01:00
|
|
|
|
2008-04-03 11:12:06 +02:00
|
|
|
static void add_child(struct rev_info *revs, struct commit *parent, struct commit *child)
|
|
|
|
{
|
|
|
|
struct commit_list *l = xcalloc(1, sizeof(*l));
|
|
|
|
|
|
|
|
l->item = child;
|
|
|
|
l->next = add_decoration(&revs->children, &parent->object, l);
|
|
|
|
}
|
|
|
|
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
static int remove_duplicate_parents(struct commit *commit)
|
|
|
|
{
|
|
|
|
struct commit_list **pp, *p;
|
|
|
|
int surviving_parents;
|
|
|
|
|
|
|
|
/* Examine existing parents while marking ones we have seen... */
|
|
|
|
pp = &commit->parents;
|
|
|
|
while ((p = *pp) != NULL) {
|
|
|
|
struct commit *parent = p->item;
|
|
|
|
if (parent->object.flags & TMP_MARK) {
|
|
|
|
*pp = p->next;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
parent->object.flags |= TMP_MARK;
|
|
|
|
pp = &p->next;
|
|
|
|
}
|
|
|
|
/* count them while clearing the temporary mark */
|
|
|
|
surviving_parents = 0;
|
|
|
|
for (p = commit->parents; p; p = p->next) {
|
|
|
|
p->item->object.flags &= ~TMP_MARK;
|
|
|
|
surviving_parents++;
|
|
|
|
}
|
|
|
|
return surviving_parents;
|
|
|
|
}
|
|
|
|
|
2008-08-14 19:59:44 +02:00
|
|
|
struct merge_simplify_state {
|
|
|
|
struct commit *simplified;
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct merge_simplify_state *locate_simplify_state(struct rev_info *revs, struct commit *commit)
|
|
|
|
{
|
|
|
|
struct merge_simplify_state *st;
|
|
|
|
|
|
|
|
st = lookup_decoration(&revs->merge_simplification, &commit->object);
|
|
|
|
if (!st) {
|
|
|
|
st = xcalloc(1, sizeof(*st));
|
|
|
|
add_decoration(&revs->merge_simplification, &commit->object, st);
|
|
|
|
}
|
|
|
|
return st;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct commit_list **simplify_one(struct rev_info *revs, struct commit *commit, struct commit_list **tail)
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
{
|
|
|
|
struct commit_list *p;
|
2008-08-14 19:59:44 +02:00
|
|
|
struct merge_simplify_state *st, *pst;
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
int cnt;
|
|
|
|
|
2008-08-14 19:59:44 +02:00
|
|
|
st = locate_simplify_state(revs, commit);
|
|
|
|
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
/*
|
|
|
|
* Have we handled this one?
|
|
|
|
*/
|
2008-08-14 19:59:44 +02:00
|
|
|
if (st->simplified)
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
return tail;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* An UNINTERESTING commit simplifies to itself, so does a
|
|
|
|
* root commit. We do not rewrite parents of such commit
|
|
|
|
* anyway.
|
|
|
|
*/
|
|
|
|
if ((commit->object.flags & UNINTERESTING) || !commit->parents) {
|
2008-08-14 19:59:44 +02:00
|
|
|
st->simplified = commit;
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
return tail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2012-06-08 23:56:03 +02:00
|
|
|
* Do we know what commit all of our parents that matter
|
|
|
|
* should be rewritten to? Otherwise we are not ready to
|
|
|
|
* rewrite this one yet.
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
*/
|
|
|
|
for (cnt = 0, p = commit->parents; p; p = p->next) {
|
2008-08-14 19:59:44 +02:00
|
|
|
pst = locate_simplify_state(revs, p->item);
|
|
|
|
if (!pst->simplified) {
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
tail = &commit_list_insert(p->item, tail)->next;
|
|
|
|
cnt++;
|
|
|
|
}
|
2012-06-08 23:56:03 +02:00
|
|
|
if (revs->first_parent_only)
|
|
|
|
break;
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
}
|
2008-08-18 09:37:34 +02:00
|
|
|
if (cnt) {
|
|
|
|
tail = &commit_list_insert(commit, tail)->next;
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
return tail;
|
2008-08-18 09:37:34 +02:00
|
|
|
}
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Rewrite our list of parents.
|
|
|
|
*/
|
2008-08-14 19:59:44 +02:00
|
|
|
for (p = commit->parents; p; p = p->next) {
|
|
|
|
pst = locate_simplify_state(revs, p->item);
|
|
|
|
p->item = pst->simplified;
|
2012-06-08 23:56:03 +02:00
|
|
|
if (revs->first_parent_only)
|
|
|
|
break;
|
2008-08-14 19:59:44 +02:00
|
|
|
}
|
2013-01-17 23:23:03 +01:00
|
|
|
|
2013-04-08 22:10:27 +02:00
|
|
|
if (revs->first_parent_only)
|
2012-06-08 23:56:03 +02:00
|
|
|
cnt = 1;
|
2013-04-08 22:10:27 +02:00
|
|
|
else
|
2013-03-28 22:37:53 +01:00
|
|
|
cnt = remove_duplicate_parents(commit);
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* It is possible that we are a merge and one side branch
|
|
|
|
* does not have any commit that touches the given paths;
|
|
|
|
* in such a case, the immediate parents will be rewritten
|
|
|
|
* to different commits.
|
|
|
|
*
|
|
|
|
* o----X X: the commit we are looking at;
|
|
|
|
* / / o: a commit that touches the paths;
|
|
|
|
* ---o----'
|
|
|
|
*
|
|
|
|
* Further reduce the parents by removing redundant parents.
|
|
|
|
*/
|
|
|
|
if (1 < cnt) {
|
|
|
|
struct commit_list *h = reduce_heads(commit->parents);
|
|
|
|
cnt = commit_list_count(h);
|
|
|
|
free_commit_list(commit->parents);
|
|
|
|
commit->parents = h;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A commit simplifies to itself if it is a root, if it is
|
|
|
|
* UNINTERESTING, if it touches the given paths, or if it is a
|
|
|
|
* merge and its parents simplifies to more than one commits
|
|
|
|
* (the first two cases are already handled at the beginning of
|
|
|
|
* this function).
|
|
|
|
*
|
|
|
|
* Otherwise, it simplifies to what its sole parent simplifies to.
|
|
|
|
*/
|
|
|
|
if (!cnt ||
|
|
|
|
(commit->object.flags & UNINTERESTING) ||
|
|
|
|
!(commit->object.flags & TREESAME) ||
|
|
|
|
(1 < cnt))
|
2008-08-14 19:59:44 +02:00
|
|
|
st->simplified = commit;
|
|
|
|
else {
|
|
|
|
pst = locate_simplify_state(revs, commit->parents->item);
|
|
|
|
st->simplified = pst->simplified;
|
|
|
|
}
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
return tail;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void simplify_merges(struct rev_info *revs)
|
|
|
|
{
|
2012-06-08 23:50:22 +02:00
|
|
|
struct commit_list *list, *next;
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
struct commit_list *yet_to_do, **tail;
|
2012-06-08 23:50:22 +02:00
|
|
|
struct commit *commit;
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
|
2008-08-14 22:52:36 +02:00
|
|
|
if (!revs->prune)
|
|
|
|
return;
|
2008-08-04 02:47:16 +02:00
|
|
|
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
/* feed the list reversed */
|
|
|
|
yet_to_do = NULL;
|
2012-06-08 23:50:22 +02:00
|
|
|
for (list = revs->commits; list; list = next) {
|
|
|
|
commit = list->item;
|
|
|
|
next = list->next;
|
|
|
|
/*
|
|
|
|
* Do not free(list) here yet; the original list
|
|
|
|
* is used later in this function.
|
|
|
|
*/
|
|
|
|
commit_list_insert(commit, &yet_to_do);
|
|
|
|
}
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
while (yet_to_do) {
|
|
|
|
list = yet_to_do;
|
|
|
|
yet_to_do = NULL;
|
|
|
|
tail = &yet_to_do;
|
|
|
|
while (list) {
|
2012-06-08 23:50:22 +02:00
|
|
|
commit = list->item;
|
|
|
|
next = list->next;
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
free(list);
|
|
|
|
list = next;
|
2008-08-14 19:59:44 +02:00
|
|
|
tail = simplify_one(revs, commit, tail);
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* clean up the result, removing the simplified ones */
|
|
|
|
list = revs->commits;
|
|
|
|
revs->commits = NULL;
|
|
|
|
tail = &revs->commits;
|
|
|
|
while (list) {
|
2008-08-14 19:59:44 +02:00
|
|
|
struct merge_simplify_state *st;
|
2012-06-08 23:50:22 +02:00
|
|
|
|
|
|
|
commit = list->item;
|
|
|
|
next = list->next;
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
free(list);
|
|
|
|
list = next;
|
2008-08-14 19:59:44 +02:00
|
|
|
st = locate_simplify_state(revs, commit);
|
|
|
|
if (st->simplified == commit)
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
tail = &commit_list_insert(commit, tail)->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-04-03 11:12:06 +02:00
|
|
|
static void set_children(struct rev_info *revs)
|
|
|
|
{
|
|
|
|
struct commit_list *l;
|
|
|
|
for (l = revs->commits; l; l = l->next) {
|
|
|
|
struct commit *commit = l->item;
|
|
|
|
struct commit_list *p;
|
|
|
|
|
|
|
|
for (p = commit->parents; p; p = p->next)
|
|
|
|
add_child(revs, p->item, commit);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-29 09:21:21 +02:00
|
|
|
void reset_revision_walk(void)
|
|
|
|
{
|
|
|
|
clear_object_flags(SEEN | ADDED | SHOWN);
|
|
|
|
}
|
|
|
|
|
2007-05-04 23:54:57 +02:00
|
|
|
int prepare_revision_walk(struct rev_info *revs)
|
2006-02-28 20:24:00 +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
|
|
|
int nr = revs->pending.nr;
|
2007-01-11 07:36:16 +01:00
|
|
|
struct object_array_entry *e, *list;
|
2012-04-25 22:35:41 +02:00
|
|
|
struct commit_list **next = &revs->commits;
|
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
|
|
|
|
2007-01-11 07:36:16 +01:00
|
|
|
e = list = revs->pending.objects;
|
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) {
|
2007-01-11 07:36:16 +01:00
|
|
|
struct commit *commit = handle_commit(revs, e->item, e->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
|
|
|
if (commit) {
|
|
|
|
if (!(commit->object.flags & SEEN)) {
|
|
|
|
commit->object.flags |= SEEN;
|
2012-04-25 22:35:41 +02:00
|
|
|
next = commit_list_append(commit, next);
|
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
|
|
|
}
|
|
|
|
}
|
2007-01-11 07:36:16 +01:00
|
|
|
e++;
|
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
|
|
|
}
|
2011-10-01 17:56:08 +02:00
|
|
|
if (!revs->leak_pending)
|
|
|
|
free(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
|
|
|
|
teach log --no-walk=unsorted, which avoids sorting
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result
(unless the two revisions share the commit date, in which case they
will retain the order given on the command line). As the commit that
introduced --no-walk (8e64006 (Teach revision machinery about
--no-walk, 2007-07-24)) points out, the sorting is intentional, to
allow things like
git log --abbrev-commit --pretty=oneline --decorate --all --no-walk
to show all refs in order by commit date.
But there are also other cases where the sorting is not wanted, such
as
<command producing revisions in order> |
git log --oneline --no-walk --stdin
To accomodate both cases, leave the decision of whether or not to sort
up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
to 'sorted' for backward-compatibility reasons.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-29 08:15:54 +02:00
|
|
|
if (revs->no_walk != REVISION_WALK_NO_WALK_UNSORTED)
|
|
|
|
commit_list_sort_by_date(&revs->commits);
|
2006-04-15 21:09:56 +02:00
|
|
|
if (revs->no_walk)
|
2007-05-04 23:54:57 +02:00
|
|
|
return 0;
|
2006-02-28 20:24:00 +01:00
|
|
|
if (revs->limited)
|
2007-05-04 23:54:57 +02:00
|
|
|
if (limit_list(revs) < 0)
|
|
|
|
return -1;
|
2006-02-28 20:24:00 +01:00
|
|
|
if (revs->topo_order)
|
2007-11-02 21:32:58 +01:00
|
|
|
sort_in_topological_order(&revs->commits, revs->lifo);
|
revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 10:17:41 +02:00
|
|
|
if (revs->simplify_merges)
|
|
|
|
simplify_merges(revs);
|
2008-04-03 11:12:06 +02:00
|
|
|
if (revs->children.name)
|
|
|
|
set_children(revs);
|
2007-05-04 23:54:57 +02:00
|
|
|
return 0;
|
2006-02-28 20:24:00 +01:00
|
|
|
}
|
|
|
|
|
2007-05-04 23:54:57 +02:00
|
|
|
enum rewrite_result {
|
|
|
|
rewrite_one_ok,
|
|
|
|
rewrite_one_noparents,
|
2010-05-14 11:31:35 +02:00
|
|
|
rewrite_one_error
|
2007-05-04 23:54:57 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp)
|
2006-03-01 00:07:20 +01:00
|
|
|
{
|
2008-07-12 20:00:57 +02:00
|
|
|
struct commit_list *cache = NULL;
|
|
|
|
|
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)
|
2008-07-12 20:00:57 +02:00
|
|
|
if (add_parents_to_list(revs, p, &revs->commits, &cache) < 0)
|
2007-05-04 23:54:57 +02:00
|
|
|
return rewrite_one_error;
|
2006-07-01 05:21:59 +02:00
|
|
|
if (p->parents && p->parents->next)
|
2007-05-04 23:54:57 +02:00
|
|
|
return rewrite_one_ok;
|
2007-11-13 08:16:08 +01:00
|
|
|
if (p->object.flags & UNINTERESTING)
|
|
|
|
return rewrite_one_ok;
|
|
|
|
if (!(p->object.flags & TREESAME))
|
2007-05-04 23:54:57 +02:00
|
|
|
return rewrite_one_ok;
|
2006-03-01 00:07:20 +01:00
|
|
|
if (!p->parents)
|
2007-05-04 23:54:57 +02:00
|
|
|
return rewrite_one_noparents;
|
2006-03-01 00:07:20 +01:00
|
|
|
*pp = p->parents->item;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-05-04 23:54:57 +02:00
|
|
|
static int 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;
|
2007-05-04 23:54:57 +02:00
|
|
|
switch (rewrite_one(revs, &parent->item)) {
|
|
|
|
case rewrite_one_ok:
|
|
|
|
break;
|
|
|
|
case rewrite_one_noparents:
|
2006-03-01 00:07:20 +01:00
|
|
|
*pp = parent->next;
|
|
|
|
continue;
|
2007-05-04 23:54:57 +02:00
|
|
|
case rewrite_one_error:
|
|
|
|
return -1;
|
2006-03-01 00:07:20 +01:00
|
|
|
}
|
|
|
|
pp = &parent->next;
|
|
|
|
}
|
2007-07-09 04:03:19 +02:00
|
|
|
remove_duplicate_parents(commit);
|
2007-05-04 23:54:57 +02:00
|
|
|
return 0;
|
2006-03-01 00:07:20 +01:00
|
|
|
}
|
|
|
|
|
2013-01-05 22:26:45 +01:00
|
|
|
static int commit_rewrite_person(struct strbuf *buf, const char *what, struct string_list *mailmap)
|
|
|
|
{
|
|
|
|
char *person, *endp;
|
|
|
|
size_t len, namelen, maillen;
|
|
|
|
const char *name;
|
|
|
|
const char *mail;
|
|
|
|
struct ident_split ident;
|
|
|
|
|
|
|
|
person = strstr(buf->buf, what);
|
|
|
|
if (!person)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
person += strlen(what);
|
|
|
|
endp = strchr(person, '\n');
|
|
|
|
if (!endp)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
len = endp - person;
|
|
|
|
|
|
|
|
if (split_ident_line(&ident, person, len))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
mail = ident.mail_begin;
|
|
|
|
maillen = ident.mail_end - ident.mail_begin;
|
|
|
|
name = ident.name_begin;
|
|
|
|
namelen = ident.name_end - ident.name_begin;
|
|
|
|
|
|
|
|
if (map_user(mailmap, &mail, &maillen, &name, &namelen)) {
|
|
|
|
struct strbuf namemail = STRBUF_INIT;
|
|
|
|
|
|
|
|
strbuf_addf(&namemail, "%.*s <%.*s>",
|
|
|
|
(int)namelen, name, (int)maillen, mail);
|
|
|
|
|
|
|
|
strbuf_splice(buf, ident.name_begin - buf->buf,
|
|
|
|
ident.mail_end - ident.name_begin + 1,
|
|
|
|
namemail.buf, namemail.len);
|
|
|
|
|
|
|
|
strbuf_release(&namemail);
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-09-18 00:43:40 +02:00
|
|
|
static int commit_match(struct commit *commit, struct rev_info *opt)
|
|
|
|
{
|
2012-09-29 06:41:28 +02:00
|
|
|
int retval;
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 21:59:58 +01:00
|
|
|
const char *encoding;
|
|
|
|
char *message;
|
2012-09-29 06:41:28 +02:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 21:59:58 +01:00
|
|
|
|
"log --author=me --grep=it" should find intersection, not union
Historically, any grep filter in "git log" family of commands were taken
as restricting to commits with any of the words in the commit log message.
However, the user almost always want to find commits "done by this person
on that topic". With "--all-match" option, a series of grep patterns can
be turned into a requirement that all of them must produce a match, but
that makes it impossible to ask for "done by me, on either this or that"
with:
log --author=me --committer=him --grep=this --grep=that
because it will require both "this" and "that" to appear.
Change the "header" parser of grep library to treat the headers specially,
and parse it as:
(all-match-OR (HEADER-AUTHOR me)
(HEADER-COMMITTER him)
(OR
(PATTERN this)
(PATTERN that) ) )
Even though the "log" command line parser doesn't give direct access to
the extended grep syntax to group terms with parentheses, this change will
cover the majority of the case the users would want.
This incidentally revealed that one test in t7002 was bogus. It ran:
log --author=Thor --grep=Thu --format='%s'
and expected (wrongly) "Thu" to match "Thursday" in the author/committer
date, but that would never match, as the timestamp in raw commit buffer
does not have the name of the day-of-the-week.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-18 05:09:06 +01:00
|
|
|
if (!opt->grep_filter.pattern_list && !opt->grep_filter.header_list)
|
2006-09-18 00:43:40 +02:00
|
|
|
return 1;
|
2012-09-29 20:59:52 +02:00
|
|
|
|
|
|
|
/* Prepend "fake" headers as needed */
|
|
|
|
if (opt->grep_filter.use_reflog_filter) {
|
2012-09-29 06:41:28 +02:00
|
|
|
strbuf_addstr(&buf, "reflog ");
|
|
|
|
get_reflog_message(&buf, opt->reflog_info);
|
|
|
|
strbuf_addch(&buf, '\n');
|
|
|
|
}
|
2012-09-29 20:59:52 +02:00
|
|
|
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 21:59:58 +01:00
|
|
|
/*
|
|
|
|
* We grep in the user's output encoding, under the assumption that it
|
|
|
|
* is the encoding they are most likely to write their grep pattern
|
|
|
|
* for. In addition, it means we will match the "notes" encoding below,
|
|
|
|
* so we will not end up with a buffer that has two different encodings
|
|
|
|
* in it.
|
|
|
|
*/
|
|
|
|
encoding = get_log_output_encoding();
|
2013-04-19 01:08:40 +02:00
|
|
|
message = logmsg_reencode(commit, NULL, encoding);
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 21:59:58 +01:00
|
|
|
|
2012-09-29 20:59:52 +02:00
|
|
|
/* Copy the commit to temporary if we are using "fake" headers */
|
|
|
|
if (buf.len)
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 21:59:58 +01:00
|
|
|
strbuf_addstr(&buf, message);
|
2012-09-29 20:59:52 +02:00
|
|
|
|
log --use-mailmap: optimize for cases without --author/--committer search
When we taught the commit_match() mechanism to pay attention to the
new --use-mailmap option, we started to unconditionally copy the
commit object to a temporary buffer, just in case we need the author
and committer lines updated via the mailmap mechanism, and rewrite
author and committer using the mailmap.
It turns out that this has a rather unpleasant performance
implications. In the linux kernel repository, running
$ git log --author='Junio C Hamano' --pretty=short >/dev/null
under /usr/bin/time, with and without --use-mailmap (the .mailmap
file is 118 entries long, the particular author does not appear in
it), cost (with warm cache):
[without --use-mailmap]
5.42user 0.26system 0:05.70elapsed 99%CPU (0avgtext+0avgdata 2005936maxresident)k
0inputs+0outputs (0major+137669minor)pagefaults 0swaps
[with --use-mailmap]
6.47user 0.30system 0:06.78elapsed 99%CPU (0avgtext+0avgdata 2006288maxresident)k
0inputs+0outputs (0major+137692minor)pagefaults 0swaps
which incurs about 20% overhead. The command is doing extra work,
so the extra cost may be justified.
But it is inexcusable to pay the cost when we do not need
author/committer match. In the same repository,
$ git log --grep='fix menuconfig on debian lenny' --pretty=short >/dev/null
shows very similar numbers as the above:
[without --use-mailmap]
5.32user 0.30system 0:05.63elapsed 99%CPU (0avgtext+0avgdata 2005984maxresident)k
0inputs+0outputs (0major+137672minor)pagefaults 0swaps
[with --use-mailmap]
6.64user 0.24system 0:06.89elapsed 99%CPU (0avgtext+0avgdata 2006320maxresident)k
0inputs+0outputs (0major+137694minor)pagefaults 0swaps
The latter case is an unnecessary performance regression. We may
want to _show_ the result with mailmap applied, but we do not have
to copy and rewrite the author/committer of all commits we try to
match if we do not query for these fields.
Trivially optimize this performace regression by limiting the
rewrites for only when we are matching with author/committer fields.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-08 09:02:49 +01:00
|
|
|
if (opt->grep_filter.header_list && opt->mailmap) {
|
2013-01-05 22:26:45 +01:00
|
|
|
if (!buf.len)
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 21:59:58 +01:00
|
|
|
strbuf_addstr(&buf, message);
|
2013-01-05 22:26:45 +01:00
|
|
|
|
|
|
|
commit_rewrite_person(&buf, "\nauthor ", opt->mailmap);
|
|
|
|
commit_rewrite_person(&buf, "\ncommitter ", opt->mailmap);
|
|
|
|
}
|
|
|
|
|
2012-09-29 06:41:29 +02:00
|
|
|
/* Append "fake" message parts as needed */
|
|
|
|
if (opt->show_notes) {
|
|
|
|
if (!buf.len)
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 21:59:58 +01:00
|
|
|
strbuf_addstr(&buf, message);
|
|
|
|
format_display_notes(commit->object.sha1, &buf, encoding, 1);
|
2012-09-29 06:41:29 +02:00
|
|
|
}
|
|
|
|
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 21:59:58 +01:00
|
|
|
/* Find either in the original commit message, or in the temporary */
|
2012-09-29 06:41:28 +02:00
|
|
|
if (buf.len)
|
|
|
|
retval = grep_buffer(&opt->grep_filter, buf.buf, buf.len);
|
|
|
|
else
|
|
|
|
retval = grep_buffer(&opt->grep_filter,
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 21:59:58 +01:00
|
|
|
message, strlen(message));
|
2012-09-29 06:41:28 +02:00
|
|
|
strbuf_release(&buf);
|
log: re-encode commit messages before grepping
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
git commit -m 'text1' --allow-empty
git commit -m 'text2' --allow-empty
git log --graph --no-walk --grep 'text2'
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-11 21:59:58 +01:00
|
|
|
logmsg_free(message, commit);
|
2012-09-29 06:41:28 +02:00
|
|
|
return retval;
|
2006-09-18 00:43:40 +02:00
|
|
|
}
|
|
|
|
|
2008-04-03 11:12:06 +02:00
|
|
|
static inline int want_ancestry(struct rev_info *revs)
|
|
|
|
{
|
2008-07-09 00:25:44 +02:00
|
|
|
return (revs->rewrite_parents || revs->children.name);
|
2008-04-03 11:12:06 +02:00
|
|
|
}
|
|
|
|
|
2009-08-19 04:34:33 +02:00
|
|
|
enum commit_action get_commit_action(struct rev_info *revs, struct commit *commit)
|
2007-11-04 21:12:05 +01:00
|
|
|
{
|
|
|
|
if (commit->object.flags & SHOWN)
|
|
|
|
return commit_ignore;
|
2009-03-20 04:47:54 +01:00
|
|
|
if (revs->unpacked && has_sha1_pack(commit->object.sha1))
|
2007-11-04 21:12:05 +01:00
|
|
|
return commit_ignore;
|
Add "--show-all" revision walker flag for debugging
It's really not very easy to visualize the commit walker, because - on
purpose - it obvously doesn't show the uninteresting commits!
This adds a "--show-all" flag to the revision walker, which will make
it show uninteresting commits too, and they'll have a '^' in front of
them (it also fixes a logic error for !verbose_header for boundary
commits - we should show the '-' even if left_right isn't shown).
A separate patch to gitk to teach it the new '^' was sent
to paulus. With the change in place, it actually is interesting
even for the cases that git doesn't have any problems with, ie
for the kernel you can do:
gitk -d --show-all v2.6.24..
and you see just how far down it has to parse things to see it all. The
use of "-d" is a good idea, since the date-ordered toposort is much better
at showing why it goes deep down (ie the date of some of those commits
after 2.6.24 is much older, because they were merged from trees that
weren't rebased).
So I think this is a useful feature even for non-debugging - just to
visualize what git does internally more.
When it actually breaks out due to the "everybody_uninteresting()"
case, it adds the uninteresting commits (both the one it's looking at
now, and the list of pending ones) to the list
This way, we really list *all* the commits we've looked at.
Because we now end up listing commits we may not even have been parsed
at all "show_log" and "show_commit" need to protect against commits
that don't have a commit buffer entry.
That second part is debatable just how it should work. Maybe we shouldn't
show such entries at all (with this patch those entries do get shown, they
just don't get any message shown with them). But I think this is a useful
case.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-09 23:02:07 +01:00
|
|
|
if (revs->show_all)
|
|
|
|
return commit_show;
|
2007-11-04 21:12:05 +01:00
|
|
|
if (commit->object.flags & UNINTERESTING)
|
|
|
|
return commit_ignore;
|
|
|
|
if (revs->min_age != -1 && (commit->date > revs->min_age))
|
|
|
|
return commit_ignore;
|
2011-03-21 11:14:06 +01:00
|
|
|
if (revs->min_parents || (revs->max_parents >= 0)) {
|
|
|
|
int n = 0;
|
|
|
|
struct commit_list *p;
|
|
|
|
for (p = commit->parents; p; p = p->next)
|
|
|
|
n++;
|
|
|
|
if ((n < revs->min_parents) ||
|
|
|
|
((revs->max_parents >= 0) && (n > revs->max_parents)))
|
|
|
|
return commit_ignore;
|
|
|
|
}
|
2007-11-04 21:12:05 +01:00
|
|
|
if (!commit_match(commit, revs))
|
|
|
|
return commit_ignore;
|
2007-11-05 22:22:34 +01:00
|
|
|
if (revs->prune && revs->dense) {
|
2007-11-04 21:12:05 +01:00
|
|
|
/* Commit without changes? */
|
2007-11-13 08:16:08 +01:00
|
|
|
if (commit->object.flags & TREESAME) {
|
2007-11-04 21:12:05 +01:00
|
|
|
/* drop merges unless we want parenthood */
|
2008-04-03 11:12:06 +02:00
|
|
|
if (!want_ancestry(revs))
|
2007-11-04 21:12:05 +01:00
|
|
|
return commit_ignore;
|
|
|
|
/* non-merge - always ignore it */
|
|
|
|
if (!commit->parents || !commit->parents->next)
|
|
|
|
return commit_ignore;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return commit_show;
|
|
|
|
}
|
|
|
|
|
2009-08-19 04:34:33 +02:00
|
|
|
enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
|
|
|
|
{
|
|
|
|
enum commit_action action = get_commit_action(revs, commit);
|
|
|
|
|
|
|
|
if (action == commit_show &&
|
|
|
|
!revs->show_all &&
|
|
|
|
revs->prune && revs->dense && want_ancestry(revs)) {
|
|
|
|
if (rewrite_parents(revs, commit) < 0)
|
|
|
|
return commit_error;
|
|
|
|
}
|
|
|
|
return action;
|
|
|
|
}
|
|
|
|
|
2006-12-20 03:25:32 +01:00
|
|
|
static struct commit *get_revision_1(struct rev_info *revs)
|
2006-02-28 20:24:00 +01:00
|
|
|
{
|
2006-12-20 03:25:32 +01:00
|
|
|
if (!revs->commits)
|
2006-02-28 20:24:00 +01:00
|
|
|
return NULL;
|
|
|
|
|
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
|
|
|
|
reflogs: clear flags properly in corner case
The reflog-walking mechanism is based on the regular
revision traversal. We just rewrite the parents of each
commit in fake_reflog_parent to point to the commit in the
next reflog entry instead of the real parents.
However, the regular revision traversal tries not to show
the same commit twice, and so sets the SHOWN flag on each
commit it shows. In a reflog, however, we may want to see
the same commit more than once if it appears in the reflog
multiple times (which easily happens, for example, if you do
a reset to a prior state).
The fake_reflog_parent function takes care of this by
clearing flags, including SHOWN. Unfortunately, it does so
at the very end of the function, and it is possible to
return early from the function if there is no fake parent to
set up (e.g., because we are at the very first reflog entry
on the branch). In such a case the flag is not cleared, and
the entry is skipped by the revision traversal machinery as
already shown.
You can see this by walking the log of a ref which is set to
its very first commit more than once (the test below shows
such a situation). In this case the reflog walk will fail to
show the entry for the initial creation of the ref.
We don't want to simply move the flag-clearing to the top of
the function; we want to make sure flags set during the
fake-parent installation are also cleared. Instead, let's
hoist the flag-clearing out of the fake_reflog_parent
function entirely. It's not really about fake parents
anyway, and the only caller is the get_revision machinery.
Reported-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-22 05:42:53 +01:00
|
|
|
if (revs->reflog_info) {
|
2007-01-11 11:47:48 +01:00
|
|
|
fake_reflog_parent(revs->reflog_info, commit);
|
reflogs: clear flags properly in corner case
The reflog-walking mechanism is based on the regular
revision traversal. We just rewrite the parents of each
commit in fake_reflog_parent to point to the commit in the
next reflog entry instead of the real parents.
However, the regular revision traversal tries not to show
the same commit twice, and so sets the SHOWN flag on each
commit it shows. In a reflog, however, we may want to see
the same commit more than once if it appears in the reflog
multiple times (which easily happens, for example, if you do
a reset to a prior state).
The fake_reflog_parent function takes care of this by
clearing flags, including SHOWN. Unfortunately, it does so
at the very end of the function, and it is possible to
return early from the function if there is no fake parent to
set up (e.g., because we are at the very first reflog entry
on the branch). In such a case the flag is not cleared, and
the entry is skipped by the revision traversal machinery as
already shown.
You can see this by walking the log of a ref which is set to
its very first commit more than once (the test below shows
such a situation). In this case the reflog walk will fail to
show the entry for the initial creation of the ref.
We don't want to simply move the flag-clearing to the top of
the function; we want to make sure flags set during the
fake-parent installation are also cleared. Instead, let's
hoist the flag-clearing out of the fake_reflog_parent
function entirely. It's not really about fake parents
anyway, and the only caller is the get_revision machinery.
Reported-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-22 05:42:53 +01:00
|
|
|
commit->object.flags &= ~(ADDED | SEEN | SHOWN);
|
|
|
|
}
|
2007-01-11 11:47:48 +01:00
|
|
|
|
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-10-31 02:37:49 +01:00
|
|
|
if (revs->max_age != -1 &&
|
revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05 22:10:06 +01:00
|
|
|
(commit->date < revs->max_age))
|
|
|
|
continue;
|
2008-07-12 20:00:57 +02:00
|
|
|
if (add_parents_to_list(revs, commit, &revs->commits, NULL) < 0)
|
2009-02-11 10:27:43 +01:00
|
|
|
die("Failed to traverse parents of commit %s",
|
|
|
|
sha1_to_hex(commit->object.sha1));
|
2006-04-02 02:35:06 +02:00
|
|
|
}
|
2006-10-31 02:37:49 +01:00
|
|
|
|
2007-11-04 21:12:05 +01:00
|
|
|
switch (simplify_commit(revs, commit)) {
|
|
|
|
case commit_ignore:
|
2006-09-18 00:43:40 +02:00
|
|
|
continue;
|
2007-11-04 21:12:05 +01:00
|
|
|
case commit_error:
|
2009-02-11 10:27:43 +01:00
|
|
|
die("Failed to simplify parents of commit %s",
|
|
|
|
sha1_to_hex(commit->object.sha1));
|
2007-11-04 21:12:05 +01:00
|
|
|
default:
|
|
|
|
return commit;
|
2006-03-28 09:58:34 +02:00
|
|
|
}
|
2006-03-01 00:07:20 +01:00
|
|
|
} while (revs->commits);
|
|
|
|
return NULL;
|
|
|
|
}
|
2006-12-20 03:25:32 +01:00
|
|
|
|
revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05 22:10:06 +01:00
|
|
|
static void gc_boundary(struct object_array *array)
|
|
|
|
{
|
|
|
|
unsigned nr = array->nr;
|
|
|
|
unsigned alloc = array->alloc;
|
|
|
|
struct object_array_entry *objects = array->objects;
|
|
|
|
|
|
|
|
if (alloc <= nr) {
|
|
|
|
unsigned i, j;
|
|
|
|
for (i = j = 0; i < nr; i++) {
|
|
|
|
if (objects[i].item->flags & SHOWN)
|
|
|
|
continue;
|
|
|
|
if (i != j)
|
|
|
|
objects[j] = objects[i];
|
|
|
|
j++;
|
|
|
|
}
|
2007-03-06 12:00:18 +01:00
|
|
|
for (i = j; i < nr; i++)
|
revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05 22:10:06 +01:00
|
|
|
objects[i].item = NULL;
|
|
|
|
array->nr = j;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-05-25 01:02:05 +02:00
|
|
|
static void create_boundary_commit_list(struct rev_info *revs)
|
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
struct commit *c;
|
|
|
|
struct object_array *array = &revs->boundary_commits;
|
|
|
|
struct object_array_entry *objects = array->objects;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If revs->commits is non-NULL at this point, an error occurred in
|
|
|
|
* get_revision_1(). Ignore the error and continue printing the
|
|
|
|
* boundary commits anyway. (This is what the code has always
|
|
|
|
* done.)
|
|
|
|
*/
|
|
|
|
if (revs->commits) {
|
|
|
|
free_commit_list(revs->commits);
|
|
|
|
revs->commits = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Put all of the actual boundary commits from revs->boundary_commits
|
|
|
|
* into revs->commits
|
|
|
|
*/
|
|
|
|
for (i = 0; i < array->nr; i++) {
|
|
|
|
c = (struct commit *)(objects[i].item);
|
|
|
|
if (!c)
|
|
|
|
continue;
|
|
|
|
if (!(c->object.flags & CHILD_SHOWN))
|
|
|
|
continue;
|
|
|
|
if (c->object.flags & (SHOWN | BOUNDARY))
|
|
|
|
continue;
|
|
|
|
c->object.flags |= BOUNDARY;
|
|
|
|
commit_list_insert(c, &revs->commits);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If revs->topo_order is set, sort the boundary commits
|
|
|
|
* in topological order
|
|
|
|
*/
|
|
|
|
sort_in_topological_order(&revs->commits, revs->lifo);
|
|
|
|
}
|
|
|
|
|
2008-05-04 12:36:54 +02:00
|
|
|
static struct commit *get_revision_internal(struct rev_info *revs)
|
2006-12-20 03:25:32 +01:00
|
|
|
{
|
|
|
|
struct commit *c = NULL;
|
revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05 22:10:06 +01:00
|
|
|
struct commit_list *l;
|
|
|
|
|
|
|
|
if (revs->boundary == 2) {
|
2008-05-25 01:02:05 +02:00
|
|
|
/*
|
|
|
|
* All of the normal commits have already been returned,
|
|
|
|
* and we are now returning boundary commits.
|
|
|
|
* create_boundary_commit_list() has populated
|
|
|
|
* revs->commits with the remaining commits to return.
|
|
|
|
*/
|
|
|
|
c = pop_commit(&revs->commits);
|
|
|
|
if (c)
|
|
|
|
c->object.flags |= SHOWN;
|
2007-01-20 23:04:02 +01:00
|
|
|
return c;
|
|
|
|
}
|
|
|
|
|
revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05 22:10:06 +01:00
|
|
|
/*
|
revision: avoid work after --max-count is reached
During a revision traversal in which --max-count has been
specified, we decrement a counter for each revision returned
by get_revision. When it hits 0, we typically return NULL
(the exception being if we still have boundary commits to
show).
However, before we check the counter, we call get_revision_1
to get the next commit. This might involve looking at a
large number of commits if we have restricted the traversal
(e.g., we might traverse until we find the next commit whose
diff actually matches a pathspec).
There's no need to make this get_revision_1 call when our
counter runs out. If we are not in --boundary mode, we will
just throw away the result and immediately return NULL. If
we are in --boundary mode, then we will still throw away the
result, and then start showing the boundary commits.
However, as git_revision_1 does not impact the boundary
list, it should not have an impact.
In most cases, avoiding this work will not be especially
noticeable. However, in some cases, it can make a big
difference:
[before]
$ time git rev-list -1 origin Documentation/RelNotes/1.7.11.2.txt
8d141a1d562abb31f27f599dbf6e10a6c06ed73e
real 0m0.301s
user 0m0.280s
sys 0m0.016s
[after]
$ time git rev-list -1 origin Documentation/RelNotes/1.7.11.2.txt
8d141a1d562abb31f27f599dbf6e10a6c06ed73e
real 0m0.010s
user 0m0.008s
sys 0m0.000s
Note that the output is produced almost instantaneously in
the first case, and then git uselessly spends a long time
looking for the next commit to touch that file (but there
isn't one, and we traverse all the way down to the roots).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-13 09:50:23 +02:00
|
|
|
* If our max_count counter has reached zero, then we are done. We
|
|
|
|
* don't simply return NULL because we still might need to show
|
|
|
|
* boundary commits. But we want to avoid calling get_revision_1, which
|
|
|
|
* might do a considerable amount of work finding the next commit only
|
|
|
|
* for us to throw it away.
|
|
|
|
*
|
|
|
|
* If it is non-zero, then either we don't have a max_count at all
|
|
|
|
* (-1), or it is still counting, in which case we decrement.
|
revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05 22:10:06 +01:00
|
|
|
*/
|
revision: avoid work after --max-count is reached
During a revision traversal in which --max-count has been
specified, we decrement a counter for each revision returned
by get_revision. When it hits 0, we typically return NULL
(the exception being if we still have boundary commits to
show).
However, before we check the counter, we call get_revision_1
to get the next commit. This might involve looking at a
large number of commits if we have restricted the traversal
(e.g., we might traverse until we find the next commit whose
diff actually matches a pathspec).
There's no need to make this get_revision_1 call when our
counter runs out. If we are not in --boundary mode, we will
just throw away the result and immediately return NULL. If
we are in --boundary mode, then we will still throw away the
result, and then start showing the boundary commits.
However, as git_revision_1 does not impact the boundary
list, it should not have an impact.
In most cases, avoiding this work will not be especially
noticeable. However, in some cases, it can make a big
difference:
[before]
$ time git rev-list -1 origin Documentation/RelNotes/1.7.11.2.txt
8d141a1d562abb31f27f599dbf6e10a6c06ed73e
real 0m0.301s
user 0m0.280s
sys 0m0.016s
[after]
$ time git rev-list -1 origin Documentation/RelNotes/1.7.11.2.txt
8d141a1d562abb31f27f599dbf6e10a6c06ed73e
real 0m0.010s
user 0m0.008s
sys 0m0.000s
Note that the output is produced almost instantaneously in
the first case, and then git uselessly spends a long time
looking for the next commit to touch that file (but there
isn't one, and we traverse all the way down to the roots).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-13 09:50:23 +02:00
|
|
|
if (revs->max_count) {
|
|
|
|
c = get_revision_1(revs);
|
|
|
|
if (c) {
|
|
|
|
while (0 < revs->skip_count) {
|
|
|
|
revs->skip_count--;
|
|
|
|
c = get_revision_1(revs);
|
|
|
|
if (!c)
|
|
|
|
break;
|
|
|
|
}
|
2007-03-06 12:20:55 +01:00
|
|
|
}
|
revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05 22:10:06 +01:00
|
|
|
|
revision: avoid work after --max-count is reached
During a revision traversal in which --max-count has been
specified, we decrement a counter for each revision returned
by get_revision. When it hits 0, we typically return NULL
(the exception being if we still have boundary commits to
show).
However, before we check the counter, we call get_revision_1
to get the next commit. This might involve looking at a
large number of commits if we have restricted the traversal
(e.g., we might traverse until we find the next commit whose
diff actually matches a pathspec).
There's no need to make this get_revision_1 call when our
counter runs out. If we are not in --boundary mode, we will
just throw away the result and immediately return NULL. If
we are in --boundary mode, then we will still throw away the
result, and then start showing the boundary commits.
However, as git_revision_1 does not impact the boundary
list, it should not have an impact.
In most cases, avoiding this work will not be especially
noticeable. However, in some cases, it can make a big
difference:
[before]
$ time git rev-list -1 origin Documentation/RelNotes/1.7.11.2.txt
8d141a1d562abb31f27f599dbf6e10a6c06ed73e
real 0m0.301s
user 0m0.280s
sys 0m0.016s
[after]
$ time git rev-list -1 origin Documentation/RelNotes/1.7.11.2.txt
8d141a1d562abb31f27f599dbf6e10a6c06ed73e
real 0m0.010s
user 0m0.008s
sys 0m0.000s
Note that the output is produced almost instantaneously in
the first case, and then git uselessly spends a long time
looking for the next commit to touch that file (but there
isn't one, and we traverse all the way down to the roots).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-13 09:50:23 +02:00
|
|
|
if (revs->max_count > 0)
|
|
|
|
revs->max_count--;
|
2006-12-20 03:25:32 +01:00
|
|
|
}
|
revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05 22:10:06 +01:00
|
|
|
|
2007-03-06 03:23:57 +01:00
|
|
|
if (c)
|
|
|
|
c->object.flags |= SHOWN;
|
|
|
|
|
|
|
|
if (!revs->boundary) {
|
2006-12-20 03:25:32 +01:00
|
|
|
return c;
|
2007-03-06 03:23:57 +01:00
|
|
|
}
|
revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05 22:10:06 +01:00
|
|
|
|
|
|
|
if (!c) {
|
|
|
|
/*
|
|
|
|
* get_revision_1() runs out the commits, and
|
|
|
|
* we are done computing the boundaries.
|
|
|
|
* switch to boundary commits output mode.
|
|
|
|
*/
|
|
|
|
revs->boundary = 2;
|
2008-05-25 01:02:05 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Update revs->commits to contain the list of
|
|
|
|
* boundary commits.
|
|
|
|
*/
|
|
|
|
create_boundary_commit_list(revs);
|
|
|
|
|
2008-05-25 01:02:04 +02:00
|
|
|
return get_revision_internal(revs);
|
revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05 22:10:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* boundary commits are the commits that are parents of the
|
|
|
|
* ones we got from get_revision_1() but they themselves are
|
|
|
|
* not returned from get_revision_1(). Before returning
|
|
|
|
* 'c', we need to mark its parents that they could be boundaries.
|
|
|
|
*/
|
|
|
|
|
|
|
|
for (l = c->parents; l; l = l->next) {
|
|
|
|
struct object *p;
|
|
|
|
p = &(l->item->object);
|
2007-03-06 03:23:57 +01:00
|
|
|
if (p->flags & (CHILD_SHOWN | SHOWN))
|
revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05 22:10:06 +01:00
|
|
|
continue;
|
|
|
|
p->flags |= CHILD_SHOWN;
|
|
|
|
gc_boundary(&revs->boundary_commits);
|
|
|
|
add_object_array(p, NULL, &revs->boundary_commits);
|
|
|
|
}
|
|
|
|
|
|
|
|
return c;
|
2006-12-20 03:25:32 +01:00
|
|
|
}
|
2008-05-04 12:36:54 +02:00
|
|
|
|
|
|
|
struct commit *get_revision(struct rev_info *revs)
|
|
|
|
{
|
2008-08-29 21:18:38 +02:00
|
|
|
struct commit *c;
|
|
|
|
struct commit_list *reversed;
|
|
|
|
|
|
|
|
if (revs->reverse) {
|
|
|
|
reversed = NULL;
|
|
|
|
while ((c = get_revision_internal(revs))) {
|
|
|
|
commit_list_insert(c, &reversed);
|
|
|
|
}
|
|
|
|
revs->commits = reversed;
|
|
|
|
revs->reverse = 0;
|
|
|
|
revs->reverse_output_stage = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (revs->reverse_output_stage)
|
|
|
|
return pop_commit(&revs->commits);
|
|
|
|
|
|
|
|
c = get_revision_internal(revs);
|
2008-05-04 12:36:54 +02:00
|
|
|
if (c && revs->graph)
|
|
|
|
graph_update(revs->graph, c);
|
|
|
|
return c;
|
|
|
|
}
|
2011-03-07 13:31:39 +01:00
|
|
|
|
|
|
|
char *get_revision_mark(const struct rev_info *revs, const struct commit *commit)
|
|
|
|
{
|
|
|
|
if (commit->object.flags & BOUNDARY)
|
|
|
|
return "-";
|
|
|
|
else if (commit->object.flags & UNINTERESTING)
|
|
|
|
return "^";
|
2011-03-07 13:31:40 +01:00
|
|
|
else if (commit->object.flags & PATCHSAME)
|
|
|
|
return "=";
|
2011-03-07 13:31:39 +01:00
|
|
|
else if (!revs || revs->left_right) {
|
|
|
|
if (commit->object.flags & SYMMETRIC_LEFT)
|
|
|
|
return "<";
|
|
|
|
else
|
|
|
|
return ">";
|
|
|
|
} else if (revs->graph)
|
|
|
|
return "*";
|
2011-03-07 13:31:40 +01:00
|
|
|
else if (revs->cherry_mark)
|
|
|
|
return "+";
|
2011-03-07 13:31:39 +01:00
|
|
|
return "";
|
|
|
|
}
|
2011-03-10 15:45:03 +01:00
|
|
|
|
|
|
|
void put_revision_mark(const struct rev_info *revs, const struct commit *commit)
|
|
|
|
{
|
|
|
|
char *mark = get_revision_mark(revs, commit);
|
|
|
|
if (!strlen(mark))
|
|
|
|
return;
|
|
|
|
fputs(mark, stdout);
|
|
|
|
putchar(' ');
|
|
|
|
}
|