2005-04-26 16:25:05 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2005 Junio C Hamano
|
|
|
|
*/
|
2005-04-26 01:22:47 +00:00
|
|
|
#include "cache.h"
|
2005-07-08 06:58:32 +00:00
|
|
|
#include "quote.h"
|
2006-04-22 06:57:45 +00:00
|
|
|
#include "commit.h"
|
2005-04-26 01:22:47 +00:00
|
|
|
#include "diff.h"
|
2005-05-21 09:39:09 +00:00
|
|
|
#include "diffcore.h"
|
2006-04-22 06:57:45 +00:00
|
|
|
#include "revision.h"
|
2007-01-30 09:11:08 +00:00
|
|
|
#include "cache-tree.h"
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
#include "unpack-trees.h"
|
2008-03-31 00:29:48 +00:00
|
|
|
#include "refs.h"
|
2005-05-21 09:39:09 +00:00
|
|
|
|
2005-05-04 08:45:24 +00:00
|
|
|
/*
|
2006-04-22 06:57:45 +00:00
|
|
|
* diff-files
|
2005-05-04 08:45:24 +00:00
|
|
|
*/
|
2005-05-27 22:56:38 +00:00
|
|
|
|
2008-03-31 00:29:48 +00:00
|
|
|
/*
|
2008-05-04 00:04:42 +00:00
|
|
|
* Has the work tree entity been removed?
|
|
|
|
*
|
|
|
|
* Return 1 if it was removed from the work tree, 0 if an entity to be
|
|
|
|
* compared with the cache entry ce still exists (the latter includes
|
|
|
|
* the case where a directory that is not a submodule repository
|
|
|
|
* exists for ce that is a submodule -- it is a submodule that is not
|
|
|
|
* checked out). Return negative for an error.
|
2008-03-31 00:29:48 +00:00
|
|
|
*/
|
Optimize symlink/directory detection
This is the base for making symlink detection in the middle fo a pathname
saner and (much) more efficient.
Under various loads, we want to verify that the full path leading up to a
filename is a real directory tree, and that when we successfully do an
'lstat()' on a filename, we don't get a false positive due to a symlink in
the middle of the path that git should have seen as a symlink, not as a
normal path component.
The 'has_symlink_leading_path()' function already did this, and cached
a single level of symlink information, but didn't cache the _lack_ of a
symlink, so the normal behaviour was actually the wrong way around, and we
ended up doing an 'lstat()' on each path component to check that it was a
real directory.
This caches the last detected full directory and symlink entries, and
speeds up especially deep directory structures a lot by avoiding to
lstat() all the directories leading up to each entry in the index.
[ This can - and should - probably be extended upon so that we eventually
never do a bare 'lstat()' on any path entries at *all* when checking the
index, but always check the full path carefully. Right now we do not
generally check the whole path for all our normal quick index
revalidation.
We should also make sure that we're careful about all the invalidation,
ie when we remove a link and replace it by a directory we should
invalidate the symlink cache if it matches (and vice versa for the
directory cache).
But regardless, the basic function needs to be sane to do that. The old
'has_symlink_leading_path()' was not capable enough - or indeed the code
readable enough - to really do that sanely. So I'm pushing this as not
just an optimization, but as a base for further work. ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-09 16:21:07 +00:00
|
|
|
static int check_removed(const struct cache_entry *ce, struct stat *st)
|
2008-03-31 00:29:48 +00:00
|
|
|
{
|
|
|
|
if (lstat(ce->name, st) < 0) {
|
|
|
|
if (errno != ENOENT && errno != ENOTDIR)
|
|
|
|
return -1;
|
|
|
|
return 1;
|
|
|
|
}
|
Optimize symlink/directory detection
This is the base for making symlink detection in the middle fo a pathname
saner and (much) more efficient.
Under various loads, we want to verify that the full path leading up to a
filename is a real directory tree, and that when we successfully do an
'lstat()' on a filename, we don't get a false positive due to a symlink in
the middle of the path that git should have seen as a symlink, not as a
normal path component.
The 'has_symlink_leading_path()' function already did this, and cached
a single level of symlink information, but didn't cache the _lack_ of a
symlink, so the normal behaviour was actually the wrong way around, and we
ended up doing an 'lstat()' on each path component to check that it was a
real directory.
This caches the last detected full directory and symlink entries, and
speeds up especially deep directory structures a lot by avoiding to
lstat() all the directories leading up to each entry in the index.
[ This can - and should - probably be extended upon so that we eventually
never do a bare 'lstat()' on any path entries at *all* when checking the
index, but always check the full path carefully. Right now we do not
generally check the whole path for all our normal quick index
revalidation.
We should also make sure that we're careful about all the invalidation,
ie when we remove a link and replace it by a directory we should
invalidate the symlink cache if it matches (and vice versa for the
directory cache).
But regardless, the basic function needs to be sane to do that. The old
'has_symlink_leading_path()' was not capable enough - or indeed the code
readable enough - to really do that sanely. So I'm pushing this as not
just an optimization, but as a base for further work. ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-09 16:21:07 +00:00
|
|
|
if (has_symlink_leading_path(ce_namelen(ce), ce->name))
|
2008-03-31 00:29:48 +00:00
|
|
|
return 1;
|
|
|
|
if (S_ISDIR(st->st_mode)) {
|
|
|
|
unsigned char sub[20];
|
2008-05-04 00:04:42 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If ce is already a gitlink, we can have a plain
|
|
|
|
* directory (i.e. the submodule is not checked out),
|
|
|
|
* or a checked out submodule. Either case this is not
|
|
|
|
* a case where something was removed from the work tree,
|
|
|
|
* so we will return 0.
|
|
|
|
*
|
|
|
|
* Otherwise, if the directory is not a submodule
|
|
|
|
* repository, that means ce which was a blob turned into
|
|
|
|
* a directory --- the blob was removed!
|
|
|
|
*/
|
|
|
|
if (!S_ISGITLINK(ce->ce_mode) &&
|
|
|
|
resolve_gitlink_ref(ce->name, "HEAD", sub))
|
2008-03-31 00:29:48 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2007-02-22 20:50:10 +00:00
|
|
|
|
2007-11-10 08:15:03 +00:00
|
|
|
int run_diff_files(struct rev_info *revs, unsigned int option)
|
2005-05-27 22:56:38 +00:00
|
|
|
{
|
2006-04-22 06:57:45 +00:00
|
|
|
int entries, i;
|
|
|
|
int diff_unmerged_stage = revs->max_count;
|
2007-11-10 08:15:03 +00:00
|
|
|
int silent_on_removed = option & DIFF_SILENT_ON_REMOVED;
|
git-add: make the entry stat-clean after re-adding the same contents
Earlier in commit 0781b8a9b2fe760fc4ed519a3a26e4b9bd6ccffe
(add_file_to_index: skip rehashing if the cached stat already
matches), add_file_to_index() were taught not to re-add the path
if it already matches the index.
The change meant well, but was not executed quite right. It
used ie_modified() to see if the file on the work tree is really
different from the index, and skipped adding the contents if the
function says "not modified".
This was wrong. There are three possible comparison results
between the index and the file in the work tree:
- with lstat(2) we _know_ they are different. E.g. if the
length or the owner in the cached stat information is
different from the length we just obtained from lstat(2), we
can tell the file is modified without looking at the actual
contents.
- with lstat(2) we _know_ they are the same. The same length,
the same owner, the same everything (but this has a twist, as
described below).
- we cannot tell from lstat(2) information alone and need to go
to the filesystem to actually compare.
The last case arises from what we call 'racy git' situation,
that can be caused with this sequence:
$ echo hello >file
$ git add file
$ echo aeiou >file ;# the same length
If the second "echo" is done within the same filesystem
timestamp granularity as the first "echo", then the timestamp
recorded by "git add" and the timestamp we get from lstat(2)
will be the same, and we can mistakenly say the file is not
modified. The path is called 'racily clean'. We need to
reliably detect racily clean paths are in fact modified.
To solve this problem, when we write out the index, we mark the
index entry that has the same timestamp as the index file itself
(that is the time from the point of view of the filesystem) to
tell any later code that does the lstat(2) comparison not to
trust the cached stat info, and ie_modified() then actually goes
to the filesystem to compare the contents for such a path.
That's all good, but it should not be used for this "git add"
optimization, as the goal of "git add" is to actually update the
path in the index and make it stat-clean. With the false
optimization, we did _not_ cause any data loss (after all, what
we failed to do was only to update the cached stat information),
but it made the following sequence leave the file stat dirty:
$ echo hello >file
$ git add file
$ echo hello >file ;# the same contents
$ git add file
The solution is not to use ie_modified() which goes to the
filesystem to see if it is really clean, but instead use
ie_match_stat() with "assume racily clean paths are dirty"
option, to force re-adding of such a path.
There was another problem with "git add -u". The codepath
shares the same issue when adding the paths that are found to be
modified, but in addition, it asked "git diff-files" machinery
run_diff_files() function (which is "git diff-files") to list
the paths that are modified. But "git diff-files" machinery
uses the same ie_modified() call so that it does not report
racily clean _and_ actually clean paths as modified, which is
not what we want.
The patch allows the callers of run_diff_files() to pass the
same "assume racily clean paths are dirty" option, and makes
"git-add -u" codepath to use that option, to discover and re-add
racily clean _and_ actually clean paths.
We could further optimize on top of this patch to differentiate
the case where the path really needs re-adding (i.e. the content
of the racily clean entry was indeed different) and the case
where only the cached stat information needs to be refreshed
(i.e. the racily clean entry was actually clean), but I do not
think it is worth it.
This patch applies to maint and all the way up.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-10 02:22:52 +00:00
|
|
|
unsigned ce_option = ((option & DIFF_RACY_IS_MODIFIED)
|
|
|
|
? CE_MATCH_RACY_IS_DIRTY : 0);
|
2008-03-31 00:30:08 +00:00
|
|
|
char symcache[PATH_MAX];
|
2005-05-27 22:56:38 +00:00
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
if (diff_unmerged_stage < 0)
|
|
|
|
diff_unmerged_stage = 2;
|
2007-02-10 02:51:40 +00:00
|
|
|
entries = active_nr;
|
2008-03-31 00:30:08 +00:00
|
|
|
symcache[0] = '\0';
|
2006-04-22 06:57:45 +00:00
|
|
|
for (i = 0; i < entries; i++) {
|
2005-04-26 16:25:05 +00:00
|
|
|
struct stat st;
|
2006-04-22 06:57:45 +00:00
|
|
|
unsigned int oldmode, newmode;
|
|
|
|
struct cache_entry *ce = active_cache[i];
|
|
|
|
int changed;
|
2006-02-26 23:51:24 +00:00
|
|
|
|
2007-11-10 19:05:14 +00:00
|
|
|
if (DIFF_OPT_TST(&revs->diffopt, QUIET) &&
|
|
|
|
DIFF_OPT_TST(&revs->diffopt, HAS_CHANGES))
|
2007-03-14 18:12:51 +00:00
|
|
|
break;
|
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
if (!ce_path_match(ce, revs->prune_data))
|
2006-02-26 23:51:24 +00:00
|
|
|
continue;
|
2005-04-26 16:25:05 +00:00
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
if (ce_stage(ce)) {
|
2006-06-18 15:18:05 +00:00
|
|
|
struct combine_diff_path *dpath;
|
2006-04-22 06:57:45 +00:00
|
|
|
int num_compare_stages = 0;
|
2006-06-18 15:18:05 +00:00
|
|
|
size_t path_len;
|
2006-04-22 06:57:45 +00:00
|
|
|
|
2006-06-18 15:18:05 +00:00
|
|
|
path_len = ce_namelen(ce);
|
|
|
|
|
2007-02-26 06:24:47 +00:00
|
|
|
dpath = xmalloc(combine_diff_path_size(5, path_len));
|
2006-06-18 15:18:05 +00:00
|
|
|
dpath->path = (char *) &(dpath->parent[5]);
|
|
|
|
|
|
|
|
dpath->next = NULL;
|
|
|
|
dpath->len = path_len;
|
|
|
|
memcpy(dpath->path, ce->name, path_len);
|
|
|
|
dpath->path[path_len] = '\0';
|
2006-08-23 20:57:23 +00:00
|
|
|
hashclr(dpath->sha1);
|
2006-06-18 15:18:05 +00:00
|
|
|
memset(&(dpath->parent[0]), 0,
|
2007-02-26 06:24:47 +00:00
|
|
|
sizeof(struct combine_diff_parent)*5);
|
|
|
|
|
Optimize symlink/directory detection
This is the base for making symlink detection in the middle fo a pathname
saner and (much) more efficient.
Under various loads, we want to verify that the full path leading up to a
filename is a real directory tree, and that when we successfully do an
'lstat()' on a filename, we don't get a false positive due to a symlink in
the middle of the path that git should have seen as a symlink, not as a
normal path component.
The 'has_symlink_leading_path()' function already did this, and cached
a single level of symlink information, but didn't cache the _lack_ of a
symlink, so the normal behaviour was actually the wrong way around, and we
ended up doing an 'lstat()' on each path component to check that it was a
real directory.
This caches the last detected full directory and symlink entries, and
speeds up especially deep directory structures a lot by avoiding to
lstat() all the directories leading up to each entry in the index.
[ This can - and should - probably be extended upon so that we eventually
never do a bare 'lstat()' on any path entries at *all* when checking the
index, but always check the full path carefully. Right now we do not
generally check the whole path for all our normal quick index
revalidation.
We should also make sure that we're careful about all the invalidation,
ie when we remove a link and replace it by a directory we should
invalidate the symlink cache if it matches (and vice versa for the
directory cache).
But regardless, the basic function needs to be sane to do that. The old
'has_symlink_leading_path()' was not capable enough - or indeed the code
readable enough - to really do that sanely. So I'm pushing this as not
just an optimization, but as a base for further work. ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-09 16:21:07 +00:00
|
|
|
changed = check_removed(ce, &st);
|
2008-03-31 00:30:08 +00:00
|
|
|
if (!changed)
|
|
|
|
dpath->mode = ce_mode_from_stat(ce, st.st_mode);
|
|
|
|
else {
|
|
|
|
if (changed < 0) {
|
2007-02-26 06:24:47 +00:00
|
|
|
perror(ce->name);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (silent_on_removed)
|
|
|
|
continue;
|
|
|
|
}
|
2006-04-22 06:57:45 +00:00
|
|
|
|
|
|
|
while (i < entries) {
|
|
|
|
struct cache_entry *nce = active_cache[i];
|
|
|
|
int stage;
|
|
|
|
|
|
|
|
if (strcmp(ce->name, nce->name))
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Stage #2 (ours) is the first parent,
|
|
|
|
* stage #3 (theirs) is the second.
|
|
|
|
*/
|
|
|
|
stage = ce_stage(nce);
|
|
|
|
if (2 <= stage) {
|
2008-01-15 00:03:17 +00:00
|
|
|
int mode = nce->ce_mode;
|
2006-04-22 06:57:45 +00:00
|
|
|
num_compare_stages++;
|
2006-08-23 06:49:00 +00:00
|
|
|
hashcpy(dpath->parent[stage-2].sha1, nce->sha1);
|
2008-01-15 00:03:17 +00:00
|
|
|
dpath->parent[stage-2].mode = ce_mode_from_stat(nce, mode);
|
2006-06-18 15:18:05 +00:00
|
|
|
dpath->parent[stage-2].status =
|
2006-04-22 06:57:45 +00:00
|
|
|
DIFF_STATUS_MODIFIED;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* diff against the proper unmerged stage */
|
|
|
|
if (stage == diff_unmerged_stage)
|
|
|
|
ce = nce;
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Compensate for loop update
|
2005-05-27 22:56:38 +00:00
|
|
|
*/
|
2006-04-22 06:57:45 +00:00
|
|
|
i--;
|
2005-09-21 07:00:47 +00:00
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
if (revs->combine_merges && num_compare_stages == 2) {
|
2006-06-18 15:18:05 +00:00
|
|
|
show_combined_diff(dpath, 2,
|
2006-04-22 06:57:45 +00:00
|
|
|
revs->dense_combined_merges,
|
|
|
|
revs);
|
2006-06-18 15:18:05 +00:00
|
|
|
free(dpath);
|
2006-04-22 06:57:45 +00:00
|
|
|
continue;
|
2005-11-21 22:17:12 +00:00
|
|
|
}
|
2006-06-18 15:18:05 +00:00
|
|
|
free(dpath);
|
|
|
|
dpath = NULL;
|
2005-06-03 08:37:54 +00:00
|
|
|
|
2006-04-22 06:57:45 +00:00
|
|
|
/*
|
|
|
|
* Show the diff for the 'ce' if we found the one
|
|
|
|
* from the desired stage.
|
|
|
|
*/
|
2007-01-05 09:25:18 +00:00
|
|
|
diff_unmerge(&revs->diffopt, ce->name, 0, null_sha1);
|
2006-04-22 06:57:45 +00:00
|
|
|
if (ce_stage(ce) != diff_unmerged_stage)
|
|
|
|
continue;
|
[PATCH] diff: Update -B heuristics.
As Linus pointed out on the mailing list discussion, -B should
break a files that has many inserts even if it still keeps
enough of the original contents, so that the broken pieces can
later be matched with other files by -M or -C. However, if such
a broken pair does not get picked up by -M or -C, we would want
to apply different criteria; namely, regardless of the amount of
new material in the result, the determination of "rewrite"
should be done by looking at the amount of original material
still left in the result. If you still have the original 97
lines from a 100-line document, it does not matter if you add
your own 13 lines to make a 110-line document, or if you add 903
lines to make a 1000-line document. It is not a rewrite but an
in-place edit. On the other hand, if you did lose 97 lines from
the original, it does not matter if you added 27 lines to make a
30-line document or if you added 997 lines to make a 1000-line
document. You did a complete rewrite in either case.
This patch introduces a post-processing phase that runs after
diffcore-rename matches up broken pairs diffcore-break creates.
The purpose of this post-processing is to pick up these broken
pieces and merge them back into in-place modifications. For
this, the score parameter -B option takes is changed into a pair
of numbers, and it takes "-B99/80" format when fully spelled
out. The first number is the minimum amount of "edit" (same
definition as what diffcore-rename uses, which is "sum of
deletion and insertion") that a modification needs to have to be
broken, and the second number is the minimum amount of "delete"
a surviving broken pair must have to avoid being merged back
together. It can be abbreviated to "-B" to use default for
both, "-B9" or "-B9/" to use 90% for "edit" but default (80%)
for merge avoidance, or "-B/75" to use default (99%) "edit" and
75% for merge avoidance.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-03 08:40:28 +00:00
|
|
|
}
|
2005-05-22 17:04:37 +00:00
|
|
|
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
if (ce_uptodate(ce))
|
|
|
|
continue;
|
2008-03-31 00:30:08 +00:00
|
|
|
|
Optimize symlink/directory detection
This is the base for making symlink detection in the middle fo a pathname
saner and (much) more efficient.
Under various loads, we want to verify that the full path leading up to a
filename is a real directory tree, and that when we successfully do an
'lstat()' on a filename, we don't get a false positive due to a symlink in
the middle of the path that git should have seen as a symlink, not as a
normal path component.
The 'has_symlink_leading_path()' function already did this, and cached
a single level of symlink information, but didn't cache the _lack_ of a
symlink, so the normal behaviour was actually the wrong way around, and we
ended up doing an 'lstat()' on each path component to check that it was a
real directory.
This caches the last detected full directory and symlink entries, and
speeds up especially deep directory structures a lot by avoiding to
lstat() all the directories leading up to each entry in the index.
[ This can - and should - probably be extended upon so that we eventually
never do a bare 'lstat()' on any path entries at *all* when checking the
index, but always check the full path carefully. Right now we do not
generally check the whole path for all our normal quick index
revalidation.
We should also make sure that we're careful about all the invalidation,
ie when we remove a link and replace it by a directory we should
invalidate the symlink cache if it matches (and vice versa for the
directory cache).
But regardless, the basic function needs to be sane to do that. The old
'has_symlink_leading_path()' was not capable enough - or indeed the code
readable enough - to really do that sanely. So I'm pushing this as not
just an optimization, but as a base for further work. ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-09 16:21:07 +00:00
|
|
|
changed = check_removed(ce, &st);
|
2008-03-31 00:30:08 +00:00
|
|
|
if (changed) {
|
|
|
|
if (changed < 0) {
|
2006-04-22 06:57:45 +00:00
|
|
|
perror(ce->name);
|
2005-05-27 22:55:55 +00:00
|
|
|
continue;
|
|
|
|
}
|
2006-04-22 06:57:45 +00:00
|
|
|
if (silent_on_removed)
|
|
|
|
continue;
|
2008-01-15 00:03:17 +00:00
|
|
|
diff_addremove(&revs->diffopt, '-', ce->ce_mode,
|
2008-07-16 14:54:02 +00:00
|
|
|
ce->sha1, ce->name);
|
2006-04-22 06:57:45 +00:00
|
|
|
continue;
|
2005-06-12 03:57:13 +00:00
|
|
|
}
|
git-add: make the entry stat-clean after re-adding the same contents
Earlier in commit 0781b8a9b2fe760fc4ed519a3a26e4b9bd6ccffe
(add_file_to_index: skip rehashing if the cached stat already
matches), add_file_to_index() were taught not to re-add the path
if it already matches the index.
The change meant well, but was not executed quite right. It
used ie_modified() to see if the file on the work tree is really
different from the index, and skipped adding the contents if the
function says "not modified".
This was wrong. There are three possible comparison results
between the index and the file in the work tree:
- with lstat(2) we _know_ they are different. E.g. if the
length or the owner in the cached stat information is
different from the length we just obtained from lstat(2), we
can tell the file is modified without looking at the actual
contents.
- with lstat(2) we _know_ they are the same. The same length,
the same owner, the same everything (but this has a twist, as
described below).
- we cannot tell from lstat(2) information alone and need to go
to the filesystem to actually compare.
The last case arises from what we call 'racy git' situation,
that can be caused with this sequence:
$ echo hello >file
$ git add file
$ echo aeiou >file ;# the same length
If the second "echo" is done within the same filesystem
timestamp granularity as the first "echo", then the timestamp
recorded by "git add" and the timestamp we get from lstat(2)
will be the same, and we can mistakenly say the file is not
modified. The path is called 'racily clean'. We need to
reliably detect racily clean paths are in fact modified.
To solve this problem, when we write out the index, we mark the
index entry that has the same timestamp as the index file itself
(that is the time from the point of view of the filesystem) to
tell any later code that does the lstat(2) comparison not to
trust the cached stat info, and ie_modified() then actually goes
to the filesystem to compare the contents for such a path.
That's all good, but it should not be used for this "git add"
optimization, as the goal of "git add" is to actually update the
path in the index and make it stat-clean. With the false
optimization, we did _not_ cause any data loss (after all, what
we failed to do was only to update the cached stat information),
but it made the following sequence leave the file stat dirty:
$ echo hello >file
$ git add file
$ echo hello >file ;# the same contents
$ git add file
The solution is not to use ie_modified() which goes to the
filesystem to see if it is really clean, but instead use
ie_match_stat() with "assume racily clean paths are dirty"
option, to force re-adding of such a path.
There was another problem with "git add -u". The codepath
shares the same issue when adding the paths that are found to be
modified, but in addition, it asked "git diff-files" machinery
run_diff_files() function (which is "git diff-files") to list
the paths that are modified. But "git diff-files" machinery
uses the same ie_modified() call so that it does not report
racily clean _and_ actually clean paths as modified, which is
not what we want.
The patch allows the callers of run_diff_files() to pass the
same "assume racily clean paths are dirty" option, and makes
"git-add -u" codepath to use that option, to discover and re-add
racily clean _and_ actually clean paths.
We could further optimize on top of this patch to differentiate
the case where the path really needs re-adding (i.e. the content
of the racily clean entry was indeed different) and the case
where only the cached stat information needs to be refreshed
(i.e. the racily clean entry was actually clean), but I do not
think it is worth it.
This patch applies to maint and all the way up.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-10 02:22:52 +00:00
|
|
|
changed = ce_match_stat(ce, &st, ce_option);
|
2008-03-30 19:39:25 +00:00
|
|
|
if (!changed) {
|
|
|
|
ce_mark_uptodate(ce);
|
|
|
|
if (!DIFF_OPT_TST(&revs->diffopt, FIND_COPIES_HARDER))
|
|
|
|
continue;
|
|
|
|
}
|
2008-01-15 00:03:17 +00:00
|
|
|
oldmode = ce->ce_mode;
|
|
|
|
newmode = ce_mode_from_stat(ce, st.st_mode);
|
2006-04-22 06:57:45 +00:00
|
|
|
diff_change(&revs->diffopt, oldmode, newmode,
|
|
|
|
ce->sha1, (changed ? null_sha1 : ce->sha1),
|
2008-07-16 14:54:02 +00:00
|
|
|
ce->name);
|
2005-04-27 16:21:00 +00:00
|
|
|
|
2005-05-20 16:54:07 +00:00
|
|
|
}
|
2006-04-22 06:57:45 +00:00
|
|
|
diffcore_std(&revs->diffopt);
|
|
|
|
diff_flush(&revs->diffopt);
|
|
|
|
return 0;
|
2005-04-27 16:21:00 +00:00
|
|
|
}
|
2005-04-26 16:25:05 +00:00
|
|
|
|
2006-04-22 09:43:00 +00:00
|
|
|
/*
|
|
|
|
* diff-index
|
|
|
|
*/
|
|
|
|
|
2008-03-31 00:29:48 +00:00
|
|
|
struct oneway_unpack_data {
|
|
|
|
struct rev_info *revs;
|
|
|
|
char symcache[PATH_MAX];
|
|
|
|
};
|
|
|
|
|
2006-04-22 09:43:00 +00:00
|
|
|
/* A file entry went away or appeared */
|
|
|
|
static void diff_index_show_file(struct rev_info *revs,
|
|
|
|
const char *prefix,
|
|
|
|
struct cache_entry *ce,
|
2008-03-02 08:57:26 +00:00
|
|
|
const unsigned char *sha1, unsigned int mode)
|
2006-04-22 09:43:00 +00:00
|
|
|
{
|
2008-01-15 00:03:17 +00:00
|
|
|
diff_addremove(&revs->diffopt, prefix[0], mode,
|
2008-07-16 14:54:02 +00:00
|
|
|
sha1, ce->name);
|
2006-04-22 09:43:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int get_stat_data(struct cache_entry *ce,
|
2008-03-02 08:57:26 +00:00
|
|
|
const unsigned char **sha1p,
|
2006-04-22 09:43:00 +00:00
|
|
|
unsigned int *modep,
|
2008-03-31 00:29:48 +00:00
|
|
|
int cached, int match_missing,
|
|
|
|
struct oneway_unpack_data *cbdata)
|
2006-04-22 09:43:00 +00:00
|
|
|
{
|
2008-03-02 08:57:26 +00:00
|
|
|
const unsigned char *sha1 = ce->sha1;
|
2006-04-22 09:43:00 +00:00
|
|
|
unsigned int mode = ce->ce_mode;
|
|
|
|
|
|
|
|
if (!cached) {
|
|
|
|
int changed;
|
|
|
|
struct stat st;
|
Optimize symlink/directory detection
This is the base for making symlink detection in the middle fo a pathname
saner and (much) more efficient.
Under various loads, we want to verify that the full path leading up to a
filename is a real directory tree, and that when we successfully do an
'lstat()' on a filename, we don't get a false positive due to a symlink in
the middle of the path that git should have seen as a symlink, not as a
normal path component.
The 'has_symlink_leading_path()' function already did this, and cached
a single level of symlink information, but didn't cache the _lack_ of a
symlink, so the normal behaviour was actually the wrong way around, and we
ended up doing an 'lstat()' on each path component to check that it was a
real directory.
This caches the last detected full directory and symlink entries, and
speeds up especially deep directory structures a lot by avoiding to
lstat() all the directories leading up to each entry in the index.
[ This can - and should - probably be extended upon so that we eventually
never do a bare 'lstat()' on any path entries at *all* when checking the
index, but always check the full path carefully. Right now we do not
generally check the whole path for all our normal quick index
revalidation.
We should also make sure that we're careful about all the invalidation,
ie when we remove a link and replace it by a directory we should
invalidate the symlink cache if it matches (and vice versa for the
directory cache).
But regardless, the basic function needs to be sane to do that. The old
'has_symlink_leading_path()' was not capable enough - or indeed the code
readable enough - to really do that sanely. So I'm pushing this as not
just an optimization, but as a base for further work. ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-09 16:21:07 +00:00
|
|
|
changed = check_removed(ce, &st);
|
2008-03-31 00:29:48 +00:00
|
|
|
if (changed < 0)
|
|
|
|
return -1;
|
|
|
|
else if (changed) {
|
|
|
|
if (match_missing) {
|
2006-04-22 09:43:00 +00:00
|
|
|
*sha1p = sha1;
|
|
|
|
*modep = mode;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
changed = ce_match_stat(ce, &st, 0);
|
|
|
|
if (changed) {
|
2007-02-17 06:43:48 +00:00
|
|
|
mode = ce_mode_from_stat(ce, st.st_mode);
|
2008-03-02 08:57:26 +00:00
|
|
|
sha1 = null_sha1;
|
2006-04-22 09:43:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
*sha1p = sha1;
|
|
|
|
*modep = mode;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-03-31 00:29:48 +00:00
|
|
|
static void show_new_file(struct oneway_unpack_data *cbdata,
|
2006-04-22 09:43:00 +00:00
|
|
|
struct cache_entry *new,
|
|
|
|
int cached, int match_missing)
|
|
|
|
{
|
2008-03-02 08:57:26 +00:00
|
|
|
const unsigned char *sha1;
|
2006-04-22 09:43:00 +00:00
|
|
|
unsigned int mode;
|
2008-03-31 00:29:48 +00:00
|
|
|
struct rev_info *revs = cbdata->revs;
|
2006-04-22 09:43:00 +00:00
|
|
|
|
2008-03-31 00:29:48 +00:00
|
|
|
/*
|
|
|
|
* New file in the index: it might actually be different in
|
2006-04-22 09:43:00 +00:00
|
|
|
* the working copy.
|
|
|
|
*/
|
2008-03-31 00:29:48 +00:00
|
|
|
if (get_stat_data(new, &sha1, &mode, cached, match_missing, cbdata) < 0)
|
2006-04-22 09:43:00 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
diff_index_show_file(revs, "+", new, sha1, mode);
|
|
|
|
}
|
|
|
|
|
2008-03-31 00:29:48 +00:00
|
|
|
static int show_modified(struct oneway_unpack_data *cbdata,
|
2006-04-22 09:43:00 +00:00
|
|
|
struct cache_entry *old,
|
|
|
|
struct cache_entry *new,
|
|
|
|
int report_missing,
|
|
|
|
int cached, int match_missing)
|
|
|
|
{
|
|
|
|
unsigned int mode, oldmode;
|
2008-03-02 08:57:26 +00:00
|
|
|
const unsigned char *sha1;
|
2008-03-31 00:29:48 +00:00
|
|
|
struct rev_info *revs = cbdata->revs;
|
2006-04-22 09:43:00 +00:00
|
|
|
|
2008-03-31 00:29:48 +00:00
|
|
|
if (get_stat_data(new, &sha1, &mode, cached, match_missing, cbdata) < 0) {
|
2006-04-22 09:43:00 +00:00
|
|
|
if (report_missing)
|
|
|
|
diff_index_show_file(revs, "-", old,
|
|
|
|
old->sha1, old->ce_mode);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2006-09-04 11:38:40 +00:00
|
|
|
if (revs->combine_merges && !cached &&
|
|
|
|
(hashcmp(sha1, old->sha1) || hashcmp(old->sha1, new->sha1))) {
|
|
|
|
struct combine_diff_path *p;
|
|
|
|
int pathlen = ce_namelen(new);
|
|
|
|
|
|
|
|
p = xmalloc(combine_diff_path_size(2, pathlen));
|
|
|
|
p->path = (char *) &p->parent[2];
|
|
|
|
p->next = NULL;
|
|
|
|
p->len = pathlen;
|
|
|
|
memcpy(p->path, new->name, pathlen);
|
|
|
|
p->path[pathlen] = 0;
|
2008-01-15 00:03:17 +00:00
|
|
|
p->mode = mode;
|
2006-09-04 11:38:40 +00:00
|
|
|
hashclr(p->sha1);
|
|
|
|
memset(p->parent, 0, 2 * sizeof(struct combine_diff_parent));
|
|
|
|
p->parent[0].status = DIFF_STATUS_MODIFIED;
|
2008-01-15 00:03:17 +00:00
|
|
|
p->parent[0].mode = new->ce_mode;
|
2006-09-04 11:38:40 +00:00
|
|
|
hashcpy(p->parent[0].sha1, new->sha1);
|
|
|
|
p->parent[1].status = DIFF_STATUS_MODIFIED;
|
2008-01-15 00:03:17 +00:00
|
|
|
p->parent[1].mode = old->ce_mode;
|
2006-09-04 11:38:40 +00:00
|
|
|
hashcpy(p->parent[1].sha1, old->sha1);
|
|
|
|
show_combined_diff(p, 2, revs->dense_combined_merges, revs);
|
|
|
|
free(p);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-04-22 09:43:00 +00:00
|
|
|
oldmode = old->ce_mode;
|
2006-08-17 18:54:57 +00:00
|
|
|
if (mode == oldmode && !hashcmp(sha1, old->sha1) &&
|
2007-11-10 19:05:14 +00:00
|
|
|
!DIFF_OPT_TST(&revs->diffopt, FIND_COPIES_HARDER))
|
2006-04-22 09:43:00 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
diff_change(&revs->diffopt, oldmode, mode,
|
2008-07-16 14:54:02 +00:00
|
|
|
old->sha1, sha1, old->name);
|
2006-04-22 09:43:00 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This turns all merge entries into "stage 3". That guarantees that
|
|
|
|
* when we read in the new tree (into "stage 1"), we won't lose sight
|
|
|
|
* of the fact that we had unmerged entries.
|
|
|
|
*/
|
|
|
|
static void mark_merge_entries(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < active_nr; i++) {
|
|
|
|
struct cache_entry *ce = active_cache[i];
|
|
|
|
if (!ce_stage(ce))
|
|
|
|
continue;
|
2008-01-15 00:03:17 +00:00
|
|
|
ce->ce_flags |= CE_STAGEMASK;
|
2006-04-22 09:43:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
/*
|
|
|
|
* This gets a mix of an existing index and a tree, one pathname entry
|
|
|
|
* at a time. The index entry may be a single stage-0 one, but it could
|
|
|
|
* also be multiple unmerged entries (in which case idx_pos/idx_nr will
|
|
|
|
* give you the position and number of entries in the index).
|
|
|
|
*/
|
|
|
|
static void do_oneway_diff(struct unpack_trees_options *o,
|
|
|
|
struct cache_entry *idx,
|
2008-03-07 02:12:28 +00:00
|
|
|
struct cache_entry *tree)
|
2006-04-22 09:43:00 +00:00
|
|
|
{
|
2008-03-31 00:29:48 +00:00
|
|
|
struct oneway_unpack_data *cbdata = o->unpack_data;
|
|
|
|
struct rev_info *revs = cbdata->revs;
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
int match_missing, cached;
|
2006-04-22 10:58:04 +00:00
|
|
|
|
2007-06-07 07:04:01 +00:00
|
|
|
/*
|
2006-04-22 10:58:04 +00:00
|
|
|
* Backward compatibility wart - "diff-index -m" does
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
* not mean "do not ignore merges", but "match_missing".
|
|
|
|
*
|
|
|
|
* But with the revision flag parsing, that's found in
|
|
|
|
* "!revs->ignore_merges".
|
|
|
|
*/
|
|
|
|
cached = o->index_only;
|
|
|
|
match_missing = !revs->ignore_merges;
|
|
|
|
|
|
|
|
if (cached && idx && ce_stage(idx)) {
|
|
|
|
if (tree)
|
|
|
|
diff_unmerge(&revs->diffopt, idx->name, idx->ce_mode, idx->sha1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Something added to the tree?
|
|
|
|
*/
|
|
|
|
if (!tree) {
|
2008-03-31 00:29:48 +00:00
|
|
|
show_new_file(cbdata, idx, cached, match_missing);
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Something removed from the tree?
|
2006-04-22 10:58:04 +00:00
|
|
|
*/
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
if (!idx) {
|
|
|
|
diff_index_show_file(revs, "-", tree, tree->sha1, tree->ce_mode);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Show difference between old and new */
|
2008-03-31 00:29:48 +00:00
|
|
|
show_modified(cbdata, tree, idx, 1, cached, match_missing);
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
}
|
|
|
|
|
2008-03-11 06:51:13 +00:00
|
|
|
static inline void skip_same_name(struct cache_entry *ce, struct unpack_trees_options *o)
|
|
|
|
{
|
|
|
|
int len = ce_namelen(ce);
|
|
|
|
const struct index_state *index = o->src_index;
|
|
|
|
|
|
|
|
while (o->pos < index->cache_nr) {
|
|
|
|
struct cache_entry *next = index->cache[o->pos];
|
|
|
|
if (len != ce_namelen(next))
|
|
|
|
break;
|
|
|
|
if (memcmp(ce->name, next->name, len))
|
|
|
|
break;
|
|
|
|
o->pos++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
/*
|
|
|
|
* The unpack_trees() interface is designed for merging, so
|
|
|
|
* the different source entries are designed primarily for
|
|
|
|
* the source trees, with the old index being really mainly
|
|
|
|
* used for being replaced by the result.
|
|
|
|
*
|
|
|
|
* For diffing, the index is more important, and we only have a
|
|
|
|
* single tree.
|
|
|
|
*
|
|
|
|
* We're supposed to return how many index entries we want to skip.
|
|
|
|
*
|
|
|
|
* This wrapper makes it all more readable, and takes care of all
|
|
|
|
* the fairly complex unpack_trees() semantic requirements, including
|
|
|
|
* the skipping, the path matching, the type conflict cases etc.
|
|
|
|
*/
|
2008-03-07 02:12:28 +00:00
|
|
|
static int oneway_diff(struct cache_entry **src, struct unpack_trees_options *o)
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
{
|
|
|
|
struct cache_entry *idx = src[0];
|
|
|
|
struct cache_entry *tree = src[1];
|
2008-03-31 00:29:48 +00:00
|
|
|
struct oneway_unpack_data *cbdata = o->unpack_data;
|
|
|
|
struct rev_info *revs = cbdata->revs;
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
|
2008-03-11 06:51:13 +00:00
|
|
|
if (idx && ce_stage(idx))
|
|
|
|
skip_same_name(idx, o);
|
|
|
|
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
/*
|
|
|
|
* Unpack-trees generates a DF/conflict entry if
|
|
|
|
* there was a directory in the index and a tree
|
|
|
|
* in the tree. From a diff standpoint, that's a
|
|
|
|
* delete of the tree and a create of the file.
|
|
|
|
*/
|
|
|
|
if (tree == o->df_conflict_entry)
|
|
|
|
tree = NULL;
|
|
|
|
|
|
|
|
if (ce_path_match(idx ? idx : tree, revs->prune_data))
|
2008-03-07 02:12:28 +00:00
|
|
|
do_oneway_diff(o, idx, tree);
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
|
2008-03-07 02:12:28 +00:00
|
|
|
return 0;
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int run_diff_index(struct rev_info *revs, int cached)
|
|
|
|
{
|
|
|
|
struct object *ent;
|
|
|
|
struct tree *tree;
|
|
|
|
const char *tree_name;
|
|
|
|
struct unpack_trees_options opts;
|
|
|
|
struct tree_desc t;
|
2008-03-31 00:29:48 +00:00
|
|
|
struct oneway_unpack_data unpack_cb;
|
2006-04-22 09:43:00 +00:00
|
|
|
|
|
|
|
mark_merge_entries();
|
|
|
|
|
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 00:42:35 +00:00
|
|
|
ent = revs->pending.objects[0].item;
|
|
|
|
tree_name = revs->pending.objects[0].name;
|
2006-04-22 09:43:00 +00:00
|
|
|
tree = parse_tree_indirect(ent->sha1);
|
|
|
|
if (!tree)
|
|
|
|
return error("bad tree object %s", tree_name);
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
|
2008-03-31 00:29:48 +00:00
|
|
|
unpack_cb.revs = revs;
|
|
|
|
unpack_cb.symcache[0] = '\0';
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
memset(&opts, 0, sizeof(opts));
|
|
|
|
opts.head_idx = 1;
|
|
|
|
opts.index_only = cached;
|
|
|
|
opts.merge = 1;
|
|
|
|
opts.fn = oneway_diff;
|
2008-03-31 00:29:48 +00:00
|
|
|
opts.unpack_data = &unpack_cb;
|
2008-03-07 02:12:28 +00:00
|
|
|
opts.src_index = &the_index;
|
|
|
|
opts.dst_index = NULL;
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
|
|
|
|
init_tree_desc(&t, tree->buffer, tree->size);
|
2008-02-07 16:39:48 +00:00
|
|
|
if (unpack_trees(1, &t, &opts))
|
|
|
|
exit(128);
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
|
2006-04-22 09:43:00 +00:00
|
|
|
diffcore_std(&revs->diffopt);
|
|
|
|
diff_flush(&revs->diffopt);
|
Make run_diff_index() use unpack_trees(), not read_tree()
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-20 01:27:12 +00:00
|
|
|
return 0;
|
2006-04-22 09:43:00 +00:00
|
|
|
}
|
2007-01-30 09:11:08 +00:00
|
|
|
|
|
|
|
int do_diff_cache(const unsigned char *tree_sha1, struct diff_options *opt)
|
|
|
|
{
|
|
|
|
struct tree *tree;
|
|
|
|
struct rev_info revs;
|
|
|
|
int i;
|
|
|
|
struct cache_entry **dst;
|
|
|
|
struct cache_entry *last = NULL;
|
2008-01-20 15:19:56 +00:00
|
|
|
struct unpack_trees_options opts;
|
|
|
|
struct tree_desc t;
|
2008-03-31 00:29:48 +00:00
|
|
|
struct oneway_unpack_data unpack_cb;
|
2007-01-30 09:11:08 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This is used by git-blame to run diff-cache internally;
|
|
|
|
* it potentially needs to repeatedly run this, so we will
|
|
|
|
* start by removing the higher order entries the last round
|
|
|
|
* left behind.
|
|
|
|
*/
|
|
|
|
dst = active_cache;
|
|
|
|
for (i = 0; i < active_nr; i++) {
|
|
|
|
struct cache_entry *ce = active_cache[i];
|
|
|
|
if (ce_stage(ce)) {
|
|
|
|
if (last && !strcmp(ce->name, last->name))
|
|
|
|
continue;
|
|
|
|
cache_tree_invalidate_path(active_cache_tree,
|
|
|
|
ce->name);
|
|
|
|
last = ce;
|
2008-01-15 00:03:17 +00:00
|
|
|
ce->ce_flags |= CE_REMOVE;
|
2007-01-30 09:11:08 +00:00
|
|
|
}
|
|
|
|
*dst++ = ce;
|
|
|
|
}
|
|
|
|
active_nr = dst - active_cache;
|
|
|
|
|
|
|
|
init_revisions(&revs, NULL);
|
|
|
|
revs.prune_data = opt->paths;
|
|
|
|
tree = parse_tree_indirect(tree_sha1);
|
|
|
|
if (!tree)
|
|
|
|
die("bad tree object %s", sha1_to_hex(tree_sha1));
|
2008-01-20 15:19:56 +00:00
|
|
|
|
2008-03-31 00:29:48 +00:00
|
|
|
unpack_cb.revs = &revs;
|
|
|
|
unpack_cb.symcache[0] = '\0';
|
2008-01-20 15:19:56 +00:00
|
|
|
memset(&opts, 0, sizeof(opts));
|
|
|
|
opts.head_idx = 1;
|
|
|
|
opts.index_only = 1;
|
|
|
|
opts.merge = 1;
|
|
|
|
opts.fn = oneway_diff;
|
2008-03-31 00:29:48 +00:00
|
|
|
opts.unpack_data = &unpack_cb;
|
2008-03-07 02:12:28 +00:00
|
|
|
opts.src_index = &the_index;
|
|
|
|
opts.dst_index = &the_index;
|
2008-01-20 15:19:56 +00:00
|
|
|
|
|
|
|
init_tree_desc(&t, tree->buffer, tree->size);
|
2008-02-07 16:39:48 +00:00
|
|
|
if (unpack_trees(1, &t, &opts))
|
|
|
|
exit(128);
|
2008-01-20 15:19:56 +00:00
|
|
|
return 0;
|
2007-01-30 09:11:08 +00:00
|
|
|
}
|