2006-09-05 12:50:12 +08:00
|
|
|
#include "cache.h"
|
|
|
|
#include "tag.h"
|
|
|
|
#include "commit.h"
|
|
|
|
#include "tree.h"
|
|
|
|
#include "blob.h"
|
|
|
|
#include "diff.h"
|
|
|
|
#include "tree-walk.h"
|
|
|
|
#include "revision.h"
|
|
|
|
#include "list-objects.h"
|
|
|
|
|
|
|
|
static void process_blob(struct rev_info *revs,
|
|
|
|
struct blob *blob,
|
process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.
I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.
Now, there are possible downsides to this:
- the "buffer using object_array" _can_ in theory result in at least
better I-cache usage (two tight loops rather than one more spread out
one). I don't think this is a real issue, but in theory..
- this _does_ change the order of the objects printed. Instead of doing a
"process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
over the commits (which puts all the root trees _first_ in the object
list, this patch just adds them to the list of pending objects, and
then we'll traverse them in that order (and thus show each root tree
object together with the objects we discover under it)
I _think_ the new ordering actually makes more sense, but the object
ordering is actually a subtle thing when it comes to packing
efficiency, so any change in order is going to have implications for
packing. Good or bad, I dunno.
- There may be some reason why we did it that odd way with the object
array, that I have simply forgotten.
Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.
This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...
Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.
Or maybe there _used_ to be a reason, and no longer is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 08:27:58 +08:00
|
|
|
show_object_fn show,
|
2006-09-05 12:50:12 +08:00
|
|
|
struct name_path *path,
|
2011-09-02 06:43:33 +08:00
|
|
|
const char *name,
|
|
|
|
void *cb_data)
|
2006-09-05 12:50:12 +08:00
|
|
|
{
|
|
|
|
struct object *obj = &blob->object;
|
|
|
|
|
|
|
|
if (!revs->blob_objects)
|
|
|
|
return;
|
2008-02-19 04:47:56 +08:00
|
|
|
if (!obj)
|
|
|
|
die("bad blob object");
|
2006-09-05 12:50:12 +08:00
|
|
|
if (obj->flags & (UNINTERESTING | SEEN))
|
|
|
|
return;
|
|
|
|
obj->flags |= SEEN;
|
2011-09-02 06:43:33 +08:00
|
|
|
show(obj, path, name, cb_data);
|
2006-09-05 12:50:12 +08:00
|
|
|
}
|
|
|
|
|
2007-04-14 00:25:01 +08:00
|
|
|
/*
|
|
|
|
* Processing a gitlink entry currently does nothing, since
|
|
|
|
* we do not recurse into the subproject.
|
|
|
|
*
|
|
|
|
* We *could* eventually add a flag that actually does that,
|
|
|
|
* which would involve:
|
|
|
|
* - is the subproject actually checked out?
|
|
|
|
* - if so, see if the subproject has already been added
|
|
|
|
* to the alternates list, and add it if not.
|
|
|
|
* - process the commit (or tag) the gitlink points to
|
|
|
|
* recursively.
|
|
|
|
*
|
|
|
|
* However, it's unclear whether there is really ever any
|
|
|
|
* reason to see superprojects and subprojects as such a
|
|
|
|
* "unified" object pool (potentially resulting in a totally
|
|
|
|
* humongous pack - avoiding which was the whole point of
|
|
|
|
* having gitlinks in the first place!).
|
|
|
|
*
|
|
|
|
* So for now, there is just a note that we *could* follow
|
|
|
|
* the link, and how to do it. Whether it necessarily makes
|
|
|
|
* any sense what-so-ever to ever do that is another issue.
|
|
|
|
*/
|
|
|
|
static void process_gitlink(struct rev_info *revs,
|
|
|
|
const unsigned char *sha1,
|
process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.
I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.
Now, there are possible downsides to this:
- the "buffer using object_array" _can_ in theory result in at least
better I-cache usage (two tight loops rather than one more spread out
one). I don't think this is a real issue, but in theory..
- this _does_ change the order of the objects printed. Instead of doing a
"process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
over the commits (which puts all the root trees _first_ in the object
list, this patch just adds them to the list of pending objects, and
then we'll traverse them in that order (and thus show each root tree
object together with the objects we discover under it)
I _think_ the new ordering actually makes more sense, but the object
ordering is actually a subtle thing when it comes to packing
efficiency, so any change in order is going to have implications for
packing. Good or bad, I dunno.
- There may be some reason why we did it that odd way with the object
array, that I have simply forgotten.
Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.
This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...
Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.
Or maybe there _used_ to be a reason, and no longer is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 08:27:58 +08:00
|
|
|
show_object_fn show,
|
2007-04-14 00:25:01 +08:00
|
|
|
struct name_path *path,
|
2011-09-02 06:43:33 +08:00
|
|
|
const char *name,
|
|
|
|
void *cb_data)
|
2007-04-14 00:25:01 +08:00
|
|
|
{
|
|
|
|
/* Nothing to do */
|
|
|
|
}
|
|
|
|
|
2006-09-05 12:50:12 +08:00
|
|
|
static void process_tree(struct rev_info *revs,
|
|
|
|
struct tree *tree,
|
process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.
I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.
Now, there are possible downsides to this:
- the "buffer using object_array" _can_ in theory result in at least
better I-cache usage (two tight loops rather than one more spread out
one). I don't think this is a real issue, but in theory..
- this _does_ change the order of the objects printed. Instead of doing a
"process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
over the commits (which puts all the root trees _first_ in the object
list, this patch just adds them to the list of pending objects, and
then we'll traverse them in that order (and thus show each root tree
object together with the objects we discover under it)
I _think_ the new ordering actually makes more sense, but the object
ordering is actually a subtle thing when it comes to packing
efficiency, so any change in order is going to have implications for
packing. Good or bad, I dunno.
- There may be some reason why we did it that odd way with the object
array, that I have simply forgotten.
Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.
This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...
Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.
Or maybe there _used_ to be a reason, and no longer is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 08:27:58 +08:00
|
|
|
show_object_fn show,
|
2006-09-05 12:50:12 +08:00
|
|
|
struct name_path *path,
|
2010-12-17 21:26:47 +08:00
|
|
|
struct strbuf *base,
|
2011-09-02 06:43:33 +08:00
|
|
|
const char *name,
|
|
|
|
void *cb_data)
|
2006-09-05 12:50:12 +08:00
|
|
|
{
|
|
|
|
struct object *obj = &tree->object;
|
|
|
|
struct tree_desc desc;
|
|
|
|
struct name_entry entry;
|
|
|
|
struct name_path me;
|
2011-10-24 14:36:10 +08:00
|
|
|
enum interesting match = revs->diffopt.pathspec.nr == 0 ?
|
|
|
|
all_entries_interesting: entry_not_interesting;
|
2010-12-17 21:26:47 +08:00
|
|
|
int baselen = base->len;
|
2006-09-05 12:50:12 +08:00
|
|
|
|
|
|
|
if (!revs->tree_objects)
|
|
|
|
return;
|
2008-02-19 04:47:56 +08:00
|
|
|
if (!obj)
|
|
|
|
die("bad tree object");
|
2006-09-05 12:50:12 +08:00
|
|
|
if (obj->flags & (UNINTERESTING | SEEN))
|
|
|
|
return;
|
|
|
|
if (parse_tree(tree) < 0)
|
|
|
|
die("bad tree object %s", sha1_to_hex(obj->sha1));
|
|
|
|
obj->flags |= SEEN;
|
2011-09-02 06:43:33 +08:00
|
|
|
show(obj, path, name, cb_data);
|
2006-09-05 12:50:12 +08:00
|
|
|
me.up = path;
|
|
|
|
me.elem = name;
|
|
|
|
me.elem_len = strlen(name);
|
|
|
|
|
2011-03-25 17:34:20 +08:00
|
|
|
if (!match) {
|
2010-12-17 21:26:47 +08:00
|
|
|
strbuf_addstr(base, name);
|
|
|
|
if (base->len)
|
|
|
|
strbuf_addch(base, '/');
|
|
|
|
}
|
|
|
|
|
2007-03-22 01:08:25 +08:00
|
|
|
init_tree_desc(&desc, tree->buffer, tree->size);
|
2006-09-05 12:50:12 +08:00
|
|
|
|
|
|
|
while (tree_entry(&desc, &entry)) {
|
2011-10-24 14:36:10 +08:00
|
|
|
if (match != all_entries_interesting) {
|
2011-03-25 17:34:20 +08:00
|
|
|
match = tree_entry_interesting(&entry, base, 0,
|
|
|
|
&revs->diffopt.pathspec);
|
2011-10-24 14:36:10 +08:00
|
|
|
if (match == all_entries_not_interesting)
|
2010-12-17 21:26:47 +08:00
|
|
|
break;
|
2011-10-24 14:36:10 +08:00
|
|
|
if (match == entry_not_interesting)
|
2010-12-17 21:26:47 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2006-09-05 12:50:12 +08:00
|
|
|
if (S_ISDIR(entry.mode))
|
|
|
|
process_tree(revs,
|
|
|
|
lookup_tree(entry.sha1),
|
2011-09-02 06:43:33 +08:00
|
|
|
show, &me, base, entry.path,
|
|
|
|
cb_data);
|
2007-05-22 04:08:28 +08:00
|
|
|
else if (S_ISGITLINK(entry.mode))
|
2007-04-14 00:25:01 +08:00
|
|
|
process_gitlink(revs, entry.sha1,
|
2011-09-02 06:43:33 +08:00
|
|
|
show, &me, entry.path,
|
|
|
|
cb_data);
|
2006-09-05 12:50:12 +08:00
|
|
|
else
|
|
|
|
process_blob(revs,
|
|
|
|
lookup_blob(entry.sha1),
|
2011-09-02 06:43:33 +08:00
|
|
|
show, &me, entry.path,
|
|
|
|
cb_data);
|
2006-09-05 12:50:12 +08:00
|
|
|
}
|
2010-12-17 21:26:47 +08:00
|
|
|
strbuf_setlen(base, baselen);
|
2013-06-06 06:37:39 +08:00
|
|
|
free_tree_buffer(tree);
|
2006-09-05 12:50:12 +08:00
|
|
|
}
|
|
|
|
|
2006-09-06 16:42:23 +08:00
|
|
|
static void mark_edge_parents_uninteresting(struct commit *commit,
|
|
|
|
struct rev_info *revs,
|
|
|
|
show_edge_fn show_edge)
|
|
|
|
{
|
|
|
|
struct commit_list *parents;
|
|
|
|
|
|
|
|
for (parents = commit->parents; parents; parents = parents->next) {
|
|
|
|
struct commit *parent = parents->item;
|
|
|
|
if (!(parent->object.flags & UNINTERESTING))
|
|
|
|
continue;
|
|
|
|
mark_tree_uninteresting(parent->tree);
|
|
|
|
if (revs->edge_hint && !(parent->object.flags & SHOWN)) {
|
|
|
|
parent->object.flags |= SHOWN;
|
|
|
|
show_edge(parent);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-08-16 17:52:06 +08:00
|
|
|
void mark_edges_uninteresting(struct rev_info *revs, show_edge_fn show_edge)
|
2006-09-06 16:42:23 +08:00
|
|
|
{
|
2013-08-16 17:52:06 +08:00
|
|
|
struct commit_list *list;
|
list-objects: mark more commits as edges in mark_edges_uninteresting
The purpose of edge commits is to let pack-objects know what objects
it can use as base, but does not need to include in the thin pack
because the other side is supposed to already have them. So far we
mark uninteresting parents of interesting commits as edges. But even
an unrelated uninteresting commit (that the other side has) may
become a good base for pack-objects and help produce more efficient
packs.
This is especially true for shallow clone, when the client issues a
fetch with a depth smaller or equal to the number of commits the
server is ahead of the client. For example, in this commit history
the client has up to "A" and the server has up to "B":
-------A---B
have--^ ^
/
want--+
If depth 1 is requested, the commit list to send to the client
includes only B. The way m_e_u is working, it checks if parent
commits of B are uninteresting, if so mark them as edges. Due to
shallow effect, commit B is grafted to have no parents and the
revision walker never sees A as the parent of B. In fact it marks no
edges at all in this simple case and sends everything B has to the
client even if it could have excluded what A and also the client
already have.
In a slightly different case where A is not a direct parent of B
(iow there are commits in between A and B), marking A as an edge can
still save some because B may still have stuff from the far ancestor
A.
There is another case from the earlier patch, when we deepen a ref
from C->E to A->E:
---A---B C---D---E
want--^ ^ ^
shallow-+ /
have-------+
In this case we need to send A and B to the client, and C (i.e. the
current shallow point that the client informs the server) is a very
good base because it's closet to A and B. Normal m_e_u won't recognize
C as an edge because it only looks back to parents (i.e. A<-B) not the
opposite way B->C even if C is already marked as uninteresting commit
by the previous patch.
This patch includes all uninteresting commits from command line as
edges and lets pack-objects decide what's best to do. The upside is we
have better chance of producing better packs in certain cases. The
downside is we may need to process some extra objects on the server
side.
For the shallow case on git.git, when the client is 5 commits behind
and does "fetch --depth=3", the result pack is 99.26 KiB instead of
4.92 MiB.
Reported-and-analyzed-by: Matthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-16 17:52:07 +08:00
|
|
|
int i;
|
|
|
|
|
2013-08-16 17:52:06 +08:00
|
|
|
for (list = revs->commits; list; list = list->next) {
|
2006-09-06 16:42:23 +08:00
|
|
|
struct commit *commit = list->item;
|
|
|
|
|
|
|
|
if (commit->object.flags & UNINTERESTING) {
|
|
|
|
mark_tree_uninteresting(commit->tree);
|
list-objects: mark more commits as edges in mark_edges_uninteresting
The purpose of edge commits is to let pack-objects know what objects
it can use as base, but does not need to include in the thin pack
because the other side is supposed to already have them. So far we
mark uninteresting parents of interesting commits as edges. But even
an unrelated uninteresting commit (that the other side has) may
become a good base for pack-objects and help produce more efficient
packs.
This is especially true for shallow clone, when the client issues a
fetch with a depth smaller or equal to the number of commits the
server is ahead of the client. For example, in this commit history
the client has up to "A" and the server has up to "B":
-------A---B
have--^ ^
/
want--+
If depth 1 is requested, the commit list to send to the client
includes only B. The way m_e_u is working, it checks if parent
commits of B are uninteresting, if so mark them as edges. Due to
shallow effect, commit B is grafted to have no parents and the
revision walker never sees A as the parent of B. In fact it marks no
edges at all in this simple case and sends everything B has to the
client even if it could have excluded what A and also the client
already have.
In a slightly different case where A is not a direct parent of B
(iow there are commits in between A and B), marking A as an edge can
still save some because B may still have stuff from the far ancestor
A.
There is another case from the earlier patch, when we deepen a ref
from C->E to A->E:
---A---B C---D---E
want--^ ^ ^
shallow-+ /
have-------+
In this case we need to send A and B to the client, and C (i.e. the
current shallow point that the client informs the server) is a very
good base because it's closet to A and B. Normal m_e_u won't recognize
C as an edge because it only looks back to parents (i.e. A<-B) not the
opposite way B->C even if C is already marked as uninteresting commit
by the previous patch.
This patch includes all uninteresting commits from command line as
edges and lets pack-objects decide what's best to do. The upside is we
have better chance of producing better packs in certain cases. The
downside is we may need to process some extra objects on the server
side.
For the shallow case on git.git, when the client is 5 commits behind
and does "fetch --depth=3", the result pack is 99.26 KiB instead of
4.92 MiB.
Reported-and-analyzed-by: Matthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-16 17:52:07 +08:00
|
|
|
if (revs->edge_hint && !(commit->object.flags & SHOWN)) {
|
|
|
|
commit->object.flags |= SHOWN;
|
|
|
|
show_edge(commit);
|
|
|
|
}
|
2006-09-06 16:42:23 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
mark_edge_parents_uninteresting(commit, revs, show_edge);
|
|
|
|
}
|
list-objects: mark more commits as edges in mark_edges_uninteresting
The purpose of edge commits is to let pack-objects know what objects
it can use as base, but does not need to include in the thin pack
because the other side is supposed to already have them. So far we
mark uninteresting parents of interesting commits as edges. But even
an unrelated uninteresting commit (that the other side has) may
become a good base for pack-objects and help produce more efficient
packs.
This is especially true for shallow clone, when the client issues a
fetch with a depth smaller or equal to the number of commits the
server is ahead of the client. For example, in this commit history
the client has up to "A" and the server has up to "B":
-------A---B
have--^ ^
/
want--+
If depth 1 is requested, the commit list to send to the client
includes only B. The way m_e_u is working, it checks if parent
commits of B are uninteresting, if so mark them as edges. Due to
shallow effect, commit B is grafted to have no parents and the
revision walker never sees A as the parent of B. In fact it marks no
edges at all in this simple case and sends everything B has to the
client even if it could have excluded what A and also the client
already have.
In a slightly different case where A is not a direct parent of B
(iow there are commits in between A and B), marking A as an edge can
still save some because B may still have stuff from the far ancestor
A.
There is another case from the earlier patch, when we deepen a ref
from C->E to A->E:
---A---B C---D---E
want--^ ^ ^
shallow-+ /
have-------+
In this case we need to send A and B to the client, and C (i.e. the
current shallow point that the client informs the server) is a very
good base because it's closet to A and B. Normal m_e_u won't recognize
C as an edge because it only looks back to parents (i.e. A<-B) not the
opposite way B->C even if C is already marked as uninteresting commit
by the previous patch.
This patch includes all uninteresting commits from command line as
edges and lets pack-objects decide what's best to do. The upside is we
have better chance of producing better packs in certain cases. The
downside is we may need to process some extra objects on the server
side.
For the shallow case on git.git, when the client is 5 commits behind
and does "fetch --depth=3", the result pack is 99.26 KiB instead of
4.92 MiB.
Reported-and-analyzed-by: Matthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-16 17:52:07 +08:00
|
|
|
for (i = 0; i < revs->cmdline.nr; i++) {
|
|
|
|
struct object *obj = revs->cmdline.rev[i].item;
|
|
|
|
struct commit *commit = (struct commit *)obj;
|
|
|
|
if (obj->type != OBJ_COMMIT || !(obj->flags & UNINTERESTING))
|
|
|
|
continue;
|
|
|
|
mark_tree_uninteresting(commit->tree);
|
|
|
|
if (revs->edge_hint && !(obj->flags & SHOWN)) {
|
|
|
|
obj->flags |= SHOWN;
|
|
|
|
show_edge(commit);
|
|
|
|
}
|
|
|
|
}
|
2006-09-06 16:42:23 +08:00
|
|
|
}
|
|
|
|
|
process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.
I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.
Now, there are possible downsides to this:
- the "buffer using object_array" _can_ in theory result in at least
better I-cache usage (two tight loops rather than one more spread out
one). I don't think this is a real issue, but in theory..
- this _does_ change the order of the objects printed. Instead of doing a
"process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
over the commits (which puts all the root trees _first_ in the object
list, this patch just adds them to the list of pending objects, and
then we'll traverse them in that order (and thus show each root tree
object together with the objects we discover under it)
I _think_ the new ordering actually makes more sense, but the object
ordering is actually a subtle thing when it comes to packing
efficiency, so any change in order is going to have implications for
packing. Good or bad, I dunno.
- There may be some reason why we did it that odd way with the object
array, that I have simply forgotten.
Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.
This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...
Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.
Or maybe there _used_ to be a reason, and no longer is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 08:27:58 +08:00
|
|
|
static void add_pending_tree(struct rev_info *revs, struct tree *tree)
|
|
|
|
{
|
|
|
|
add_pending_object(revs, &tree->object, "");
|
|
|
|
}
|
|
|
|
|
2006-09-05 12:50:12 +08:00
|
|
|
void traverse_commit_list(struct rev_info *revs,
|
2009-04-07 03:28:36 +08:00
|
|
|
show_commit_fn show_commit,
|
|
|
|
show_object_fn show_object,
|
|
|
|
void *data)
|
2006-09-05 12:50:12 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct commit *commit;
|
2010-12-17 21:26:47 +08:00
|
|
|
struct strbuf base;
|
2006-09-05 12:50:12 +08:00
|
|
|
|
2010-12-17 21:26:47 +08:00
|
|
|
strbuf_init(&base, PATH_MAX);
|
2006-09-05 12:50:12 +08:00
|
|
|
while ((commit = get_revision(revs)) != NULL) {
|
2011-03-15 03:29:50 +08:00
|
|
|
/*
|
|
|
|
* an uninteresting boundary commit may not have its tree
|
|
|
|
* parsed yet, but we are not going to show them anyway
|
|
|
|
*/
|
|
|
|
if (commit->tree)
|
|
|
|
add_pending_tree(revs, commit->tree);
|
2009-04-07 03:28:36 +08:00
|
|
|
show_commit(commit, data);
|
2006-09-05 12:50:12 +08:00
|
|
|
}
|
|
|
|
for (i = 0; i < revs->pending.nr; i++) {
|
|
|
|
struct object_array_entry *pending = revs->pending.objects + i;
|
|
|
|
struct object *obj = pending->item;
|
|
|
|
const char *name = pending->name;
|
|
|
|
if (obj->flags & (UNINTERESTING | SEEN))
|
|
|
|
continue;
|
|
|
|
if (obj->type == OBJ_TAG) {
|
|
|
|
obj->flags |= SEEN;
|
2011-09-02 06:43:33 +08:00
|
|
|
show_object(obj, NULL, name, data);
|
2006-09-05 12:50:12 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (obj->type == OBJ_TREE) {
|
process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.
I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.
Now, there are possible downsides to this:
- the "buffer using object_array" _can_ in theory result in at least
better I-cache usage (two tight loops rather than one more spread out
one). I don't think this is a real issue, but in theory..
- this _does_ change the order of the objects printed. Instead of doing a
"process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
over the commits (which puts all the root trees _first_ in the object
list, this patch just adds them to the list of pending objects, and
then we'll traverse them in that order (and thus show each root tree
object together with the objects we discover under it)
I _think_ the new ordering actually makes more sense, but the object
ordering is actually a subtle thing when it comes to packing
efficiency, so any change in order is going to have implications for
packing. Good or bad, I dunno.
- There may be some reason why we did it that odd way with the object
array, that I have simply forgotten.
Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.
This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...
Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.
Or maybe there _used_ to be a reason, and no longer is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 08:27:58 +08:00
|
|
|
process_tree(revs, (struct tree *)obj, show_object,
|
2011-09-02 06:43:33 +08:00
|
|
|
NULL, &base, name, data);
|
2006-09-05 12:50:12 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (obj->type == OBJ_BLOB) {
|
process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.
I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.
Now, there are possible downsides to this:
- the "buffer using object_array" _can_ in theory result in at least
better I-cache usage (two tight loops rather than one more spread out
one). I don't think this is a real issue, but in theory..
- this _does_ change the order of the objects printed. Instead of doing a
"process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
over the commits (which puts all the root trees _first_ in the object
list, this patch just adds them to the list of pending objects, and
then we'll traverse them in that order (and thus show each root tree
object together with the objects we discover under it)
I _think_ the new ordering actually makes more sense, but the object
ordering is actually a subtle thing when it comes to packing
efficiency, so any change in order is going to have implications for
packing. Good or bad, I dunno.
- There may be some reason why we did it that odd way with the object
array, that I have simply forgotten.
Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.
This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...
Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.
Or maybe there _used_ to be a reason, and no longer is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 08:27:58 +08:00
|
|
|
process_blob(revs, (struct blob *)obj, show_object,
|
2011-09-02 06:43:33 +08:00
|
|
|
NULL, name, data);
|
2006-09-05 12:50:12 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
die("unknown pending object %s (%s)",
|
|
|
|
sha1_to_hex(obj->sha1), name);
|
|
|
|
}
|
2007-11-09 19:06:10 +08:00
|
|
|
if (revs->pending.nr) {
|
|
|
|
free(revs->pending.objects);
|
|
|
|
revs->pending.nr = 0;
|
|
|
|
revs->pending.alloc = 0;
|
|
|
|
revs->pending.objects = NULL;
|
|
|
|
}
|
2010-12-17 21:26:47 +08:00
|
|
|
strbuf_release(&base);
|
2006-09-05 12:50:12 +08:00
|
|
|
}
|