2005-04-27 00:25:05 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2005 Junio C Hamano
|
|
|
|
*/
|
2005-04-26 09:22:47 +08:00
|
|
|
#include "cache.h"
|
2005-07-08 14:58:32 +08:00
|
|
|
#include "quote.h"
|
2006-04-22 14:57:45 +08:00
|
|
|
#include "commit.h"
|
2005-04-26 09:22:47 +08:00
|
|
|
#include "diff.h"
|
2005-05-21 17:39:09 +08:00
|
|
|
#include "diffcore.h"
|
2023-03-21 14:25:54 +08:00
|
|
|
#include "gettext.h"
|
2023-02-24 08:09:27 +08:00
|
|
|
#include "hex.h"
|
2006-04-22 14:57:45 +08:00
|
|
|
#include "revision.h"
|
2007-01-30 17:11:08 +08: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 09:27:12 +08:00
|
|
|
#include "unpack-trees.h"
|
2008-03-31 08:29:48 +08:00
|
|
|
#include "refs.h"
|
2010-01-17 01:42:24 +08:00
|
|
|
#include "submodule.h"
|
2014-01-24 21:40:28 +08:00
|
|
|
#include "dir.h"
|
2017-09-23 00:35:40 +08:00
|
|
|
#include "fsmonitor.h"
|
2020-09-20 19:22:23 +08:00
|
|
|
#include "commit-reach.h"
|
2005-05-21 17:39:09 +08:00
|
|
|
|
2005-05-04 16:45:24 +08:00
|
|
|
/*
|
2006-04-22 14:57:45 +08:00
|
|
|
* diff-files
|
2005-05-04 16:45:24 +08:00
|
|
|
*/
|
2005-05-28 06:56:38 +08:00
|
|
|
|
2008-03-31 08:29:48 +08:00
|
|
|
/*
|
2008-05-04 08:04:42 +08: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 08:29:48 +08:00
|
|
|
*/
|
2021-03-18 05:22:22 +08:00
|
|
|
static int check_removed(const struct index_state *istate, const struct cache_entry *ce, struct stat *st)
|
2008-03-31 08:29:48 +08:00
|
|
|
{
|
2021-03-18 05:22:22 +08:00
|
|
|
assert(is_fsmonitor_refreshed(istate));
|
2021-03-18 05:22:21 +08:00
|
|
|
if (!(ce->ce_flags & CE_FSMONITOR_VALID) && lstat(ce->name, st) < 0) {
|
2017-05-30 08:23:33 +08:00
|
|
|
if (!is_missing_file_error(errno))
|
2008-03-31 08:29:48 +08:00
|
|
|
return -1;
|
|
|
|
return 1;
|
|
|
|
}
|
2009-02-10 04:54:06 +08:00
|
|
|
if (has_symlink_leading_path(ce->name, ce_namelen(ce)))
|
2008-03-31 08:29:48 +08:00
|
|
|
return 1;
|
|
|
|
if (S_ISDIR(st->st_mode)) {
|
2017-10-16 06:07:06 +08:00
|
|
|
struct object_id sub;
|
2008-05-04 08:04:42 +08: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) &&
|
refs: convert resolve_gitlink_ref to struct object_id
Convert the declaration and definition of resolve_gitlink_ref to use
struct object_id and apply the following semantic patch:
@@
expression E1, E2, E3;
@@
- resolve_gitlink_ref(E1, E2, E3.hash)
+ resolve_gitlink_ref(E1, E2, &E3)
@@
expression E1, E2, E3;
@@
- resolve_gitlink_ref(E1, E2, E3->hash)
+ resolve_gitlink_ref(E1, E2, E3)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-16 06:07:07 +08:00
|
|
|
resolve_gitlink_ref(ce->name, "HEAD", &sub))
|
2008-03-31 08:29:48 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2007-02-23 04:50:10 +08:00
|
|
|
|
2010-03-12 05:50:25 +08:00
|
|
|
/*
|
|
|
|
* Has a file changed or has a submodule new commits or a dirty work tree?
|
|
|
|
*
|
|
|
|
* Return 1 when changes are detected, 0 otherwise. If the DIRTY_SUBMODULES
|
|
|
|
* option is set, the caller does not only want to know if a submodule is
|
|
|
|
* modified at all but wants to know all the conditions that are met (new
|
|
|
|
* commits, untracked content and/or modified content).
|
|
|
|
*/
|
|
|
|
static int match_stat_with_submodule(struct diff_options *diffopt,
|
2013-06-02 23:46:55 +08:00
|
|
|
const struct cache_entry *ce,
|
|
|
|
struct stat *st, unsigned ce_option,
|
|
|
|
unsigned *dirty_submodule)
|
2010-03-12 05:50:25 +08:00
|
|
|
{
|
2018-09-21 23:57:26 +08:00
|
|
|
int changed = ie_match_stat(diffopt->repo->index, ce, st, ce_option);
|
2010-08-06 06:39:25 +08:00
|
|
|
if (S_ISGITLINK(ce->ce_mode)) {
|
2017-11-01 02:19:05 +08:00
|
|
|
struct diff_flags orig_flags = diffopt->flags;
|
2017-11-01 02:19:11 +08:00
|
|
|
if (!diffopt->flags.override_submodule_config)
|
2010-08-06 06:39:25 +08:00
|
|
|
set_diffopt_flags_from_submodule_config(diffopt, ce->name);
|
2017-11-01 02:19:11 +08:00
|
|
|
if (diffopt->flags.ignore_submodules)
|
2010-08-06 06:39:25 +08:00
|
|
|
changed = 0;
|
2017-11-01 02:19:11 +08:00
|
|
|
else if (!diffopt->flags.ignore_dirty_submodules &&
|
|
|
|
(!changed || diffopt->flags.dirty_submodules))
|
2017-11-01 02:19:08 +08:00
|
|
|
*dirty_submodule = is_submodule_modified(ce->name,
|
2017-11-01 02:19:11 +08:00
|
|
|
diffopt->flags.ignore_untracked_in_submodules);
|
2010-08-06 06:39:25 +08:00
|
|
|
diffopt->flags = orig_flags;
|
2010-03-12 05:50:25 +08:00
|
|
|
}
|
|
|
|
return changed;
|
|
|
|
}
|
|
|
|
|
2007-11-10 16:15:03 +08:00
|
|
|
int run_diff_files(struct rev_info *revs, unsigned int option)
|
2005-05-28 06:56:38 +08:00
|
|
|
{
|
2006-04-22 14:57:45 +08:00
|
|
|
int entries, i;
|
|
|
|
int diff_unmerged_stage = revs->max_count;
|
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 10:22:52 +08:00
|
|
|
unsigned ce_option = ((option & DIFF_RACY_IS_MODIFIED)
|
|
|
|
? CE_MATCH_RACY_IS_DIRTY : 0);
|
2018-01-27 20:27:56 +08:00
|
|
|
uint64_t start = getnanotime();
|
2018-09-21 23:57:26 +08:00
|
|
|
struct index_state *istate = revs->diffopt.repo->index;
|
2005-05-28 06:56:38 +08:00
|
|
|
|
2008-08-19 11:08:09 +08:00
|
|
|
diff_set_mnemonic_prefix(&revs->diffopt, "i/", "w/");
|
|
|
|
|
2020-10-20 21:40:58 +08:00
|
|
|
refresh_fsmonitor(istate);
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (diff_unmerged_stage < 0)
|
|
|
|
diff_unmerged_stage = 2;
|
2018-09-21 23:57:26 +08:00
|
|
|
entries = istate->cache_nr;
|
2006-04-22 14:57:45 +08:00
|
|
|
for (i = 0; i < entries; i++) {
|
|
|
|
unsigned int oldmode, newmode;
|
2018-09-21 23:57:26 +08:00
|
|
|
struct cache_entry *ce = istate->cache[i];
|
2006-04-22 14:57:45 +08:00
|
|
|
int changed;
|
2010-01-19 04:26:18 +08:00
|
|
|
unsigned dirty_submodule = 0;
|
2017-05-31 01:30:48 +08:00
|
|
|
const struct object_id *old_oid, *new_oid;
|
2006-02-27 07:51:24 +08:00
|
|
|
|
2011-06-01 00:14:17 +08:00
|
|
|
if (diff_can_quit_early(&revs->diffopt))
|
2007-03-15 02:12:51 +08:00
|
|
|
break;
|
|
|
|
|
2018-09-21 23:57:26 +08:00
|
|
|
if (!ce_path_match(istate, ce, &revs->prune_data, NULL))
|
2006-02-27 07:51:24 +08:00
|
|
|
continue;
|
2005-04-27 00:25:05 +08:00
|
|
|
|
2021-08-22 16:49:08 +08:00
|
|
|
if (revs->diffopt.prefix &&
|
|
|
|
strncmp(ce->name, revs->diffopt.prefix, revs->diffopt.prefix_length))
|
|
|
|
continue;
|
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (ce_stage(ce)) {
|
2006-06-18 23:18:05 +08:00
|
|
|
struct combine_diff_path *dpath;
|
2011-04-23 07:19:27 +08:00
|
|
|
struct diff_filepair *pair;
|
|
|
|
unsigned int wt_mode = 0;
|
2006-04-22 14:57:45 +08:00
|
|
|
int num_compare_stages = 0;
|
2006-06-18 23:18:05 +08:00
|
|
|
size_t path_len;
|
run_diff_files: do not look at uninitialized stat data
If we try to diff an index entry marked CE_VALID (because it
was marked with --assume-unchanged), we do not bother even
running stat() on the file to see if it was removed. This
started long ago with 540e694 (Prevent diff machinery from
examining assume-unchanged entries on worktree, 2009-08-11).
However, the subsequent code may look at our "struct stat"
and expect to find actual data; currently it will find
whatever cruft was left on the stack. This can cause
problems in two situations:
1. We call match_stat_with_submodule with the stat data,
so a submodule may be erroneously marked as changed.
2. If --find-copies-harder is in effect, we pass all
entries, even unchanged ones, to diff_change, so it can
list them as rename/copy sources. Since we found no
change, we assume that function will realize it and not
actually display any diff output. However, we end up
feeding it a bogus mode, leading it to sometimes claim
there was a mode change.
We can fix both by splitting the CE_VALID and regular code
paths, and making sure only to look at the stat information
in the latter. Furthermore, we push the declaration of our
"struct stat" down into the code paths that actually set it,
so we cannot accidentally access it uninitialized in future
code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-15 06:13:06 +08:00
|
|
|
struct stat st;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
2006-06-18 23:18:05 +08:00
|
|
|
path_len = ce_namelen(ce);
|
|
|
|
|
2007-02-26 14:24:47 +08:00
|
|
|
dpath = xmalloc(combine_diff_path_size(5, path_len));
|
2006-06-18 23:18:05 +08:00
|
|
|
dpath->path = (char *) &(dpath->parent[5]);
|
|
|
|
|
|
|
|
dpath->next = NULL;
|
|
|
|
memcpy(dpath->path, ce->name, path_len);
|
|
|
|
dpath->path[path_len] = '\0';
|
2015-03-14 07:39:33 +08:00
|
|
|
oidclr(&dpath->oid);
|
2006-06-18 23:18:05 +08:00
|
|
|
memset(&(dpath->parent[0]), 0,
|
2007-02-26 14:24:47 +08:00
|
|
|
sizeof(struct combine_diff_parent)*5);
|
|
|
|
|
2021-03-18 05:22:22 +08:00
|
|
|
changed = check_removed(istate, ce, &st);
|
2008-03-31 08:30:08 +08:00
|
|
|
if (!changed)
|
2011-04-23 07:19:27 +08:00
|
|
|
wt_mode = ce_mode_from_stat(ce, st.st_mode);
|
2008-03-31 08:30:08 +08:00
|
|
|
else {
|
|
|
|
if (changed < 0) {
|
2007-02-26 14:24:47 +08:00
|
|
|
perror(ce->name);
|
|
|
|
continue;
|
|
|
|
}
|
2011-04-23 07:19:27 +08:00
|
|
|
wt_mode = 0;
|
2007-02-26 14:24:47 +08:00
|
|
|
}
|
2011-04-23 07:19:27 +08:00
|
|
|
dpath->mode = wt_mode;
|
2006-04-22 14:57:45 +08:00
|
|
|
|
|
|
|
while (i < entries) {
|
2018-09-21 23:57:26 +08:00
|
|
|
struct cache_entry *nce = istate->cache[i];
|
2006-04-22 14:57:45 +08:00
|
|
|
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 08:03:17 +08:00
|
|
|
int mode = nce->ce_mode;
|
2006-04-22 14:57:45 +08:00
|
|
|
num_compare_stages++;
|
2016-09-06 04:07:52 +08:00
|
|
|
oidcpy(&dpath->parent[stage - 2].oid,
|
|
|
|
&nce->oid);
|
2008-01-15 08:03:17 +08:00
|
|
|
dpath->parent[stage-2].mode = ce_mode_from_stat(nce, mode);
|
2006-06-18 23:18:05 +08:00
|
|
|
dpath->parent[stage-2].status =
|
2006-04-22 14:57:45 +08:00
|
|
|
DIFF_STATUS_MODIFIED;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* diff against the proper unmerged stage */
|
|
|
|
if (stage == diff_unmerged_stage)
|
|
|
|
ce = nce;
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Compensate for loop update
|
2005-05-28 06:56:38 +08:00
|
|
|
*/
|
2006-04-22 14:57:45 +08:00
|
|
|
i--;
|
2005-09-21 15:00:47 +08:00
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
if (revs->combine_merges && num_compare_stages == 2) {
|
2020-09-29 19:31:22 +08:00
|
|
|
show_combined_diff(dpath, 2, revs);
|
2006-06-18 23:18:05 +08:00
|
|
|
free(dpath);
|
2006-04-22 14:57:45 +08:00
|
|
|
continue;
|
2005-11-22 06:17:12 +08:00
|
|
|
}
|
2017-06-16 07:15:46 +08:00
|
|
|
FREE_AND_NULL(dpath);
|
2005-06-03 16:37:54 +08:00
|
|
|
|
2006-04-22 14:57:45 +08:00
|
|
|
/*
|
|
|
|
* Show the diff for the 'ce' if we found the one
|
|
|
|
* from the desired stage.
|
|
|
|
*/
|
2011-04-23 07:19:27 +08:00
|
|
|
pair = diff_unmerge(&revs->diffopt, ce->name);
|
|
|
|
if (wt_mode)
|
|
|
|
pair->two->mode = wt_mode;
|
2006-04-22 14:57:45 +08: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 16:40:28 +08:00
|
|
|
}
|
2005-05-23 01:04:37 +08:00
|
|
|
|
2010-01-24 16:10:20 +08:00
|
|
|
if (ce_uptodate(ce) || ce_skip_worktree(ce))
|
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 09:27:12 +08:00
|
|
|
continue;
|
2008-03-31 08:30:08 +08:00
|
|
|
|
2020-10-20 21:40:58 +08:00
|
|
|
/*
|
|
|
|
* When CE_VALID is set (via "update-index --assume-unchanged"
|
|
|
|
* or via adding paths while core.ignorestat is set to true),
|
|
|
|
* the user has promised that the working tree file for that
|
|
|
|
* path will not be modified. When CE_FSMONITOR_VALID is true,
|
|
|
|
* the fsmonitor knows that the path hasn't been modified since
|
|
|
|
* we refreshed the cached stat information. In either case,
|
|
|
|
* we do not have to stat to see if the path has been removed
|
|
|
|
* or modified.
|
|
|
|
*/
|
|
|
|
if (ce->ce_flags & (CE_VALID | CE_FSMONITOR_VALID)) {
|
run_diff_files: do not look at uninitialized stat data
If we try to diff an index entry marked CE_VALID (because it
was marked with --assume-unchanged), we do not bother even
running stat() on the file to see if it was removed. This
started long ago with 540e694 (Prevent diff machinery from
examining assume-unchanged entries on worktree, 2009-08-11).
However, the subsequent code may look at our "struct stat"
and expect to find actual data; currently it will find
whatever cruft was left on the stack. This can cause
problems in two situations:
1. We call match_stat_with_submodule with the stat data,
so a submodule may be erroneously marked as changed.
2. If --find-copies-harder is in effect, we pass all
entries, even unchanged ones, to diff_change, so it can
list them as rename/copy sources. Since we found no
change, we assume that function will realize it and not
actually display any diff output. However, we end up
feeding it a bogus mode, leading it to sometimes claim
there was a mode change.
We can fix both by splitting the CE_VALID and regular code
paths, and making sure only to look at the stat information
in the latter. Furthermore, we push the declaration of our
"struct stat" down into the code paths that actually set it,
so we cannot accidentally access it uninitialized in future
code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-15 06:13:06 +08:00
|
|
|
changed = 0;
|
|
|
|
newmode = ce->ce_mode;
|
|
|
|
} else {
|
|
|
|
struct stat st;
|
|
|
|
|
2021-03-18 05:22:22 +08:00
|
|
|
changed = check_removed(istate, ce, &st);
|
run_diff_files: do not look at uninitialized stat data
If we try to diff an index entry marked CE_VALID (because it
was marked with --assume-unchanged), we do not bother even
running stat() on the file to see if it was removed. This
started long ago with 540e694 (Prevent diff machinery from
examining assume-unchanged entries on worktree, 2009-08-11).
However, the subsequent code may look at our "struct stat"
and expect to find actual data; currently it will find
whatever cruft was left on the stack. This can cause
problems in two situations:
1. We call match_stat_with_submodule with the stat data,
so a submodule may be erroneously marked as changed.
2. If --find-copies-harder is in effect, we pass all
entries, even unchanged ones, to diff_change, so it can
list them as rename/copy sources. Since we found no
change, we assume that function will realize it and not
actually display any diff output. However, we end up
feeding it a bogus mode, leading it to sometimes claim
there was a mode change.
We can fix both by splitting the CE_VALID and regular code
paths, and making sure only to look at the stat information
in the latter. Furthermore, we push the declaration of our
"struct stat" down into the code paths that actually set it,
so we cannot accidentally access it uninitialized in future
code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-15 06:13:06 +08:00
|
|
|
if (changed) {
|
|
|
|
if (changed < 0) {
|
|
|
|
perror(ce->name);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
diff_addremove(&revs->diffopt, '-', ce->ce_mode,
|
2017-05-31 01:30:47 +08:00
|
|
|
&ce->oid,
|
2016-09-06 04:07:52 +08:00
|
|
|
!is_null_oid(&ce->oid),
|
run_diff_files: do not look at uninitialized stat data
If we try to diff an index entry marked CE_VALID (because it
was marked with --assume-unchanged), we do not bother even
running stat() on the file to see if it was removed. This
started long ago with 540e694 (Prevent diff machinery from
examining assume-unchanged entries on worktree, 2009-08-11).
However, the subsequent code may look at our "struct stat"
and expect to find actual data; currently it will find
whatever cruft was left on the stack. This can cause
problems in two situations:
1. We call match_stat_with_submodule with the stat data,
so a submodule may be erroneously marked as changed.
2. If --find-copies-harder is in effect, we pass all
entries, even unchanged ones, to diff_change, so it can
list them as rename/copy sources. Since we found no
change, we assume that function will realize it and not
actually display any diff output. However, we end up
feeding it a bogus mode, leading it to sometimes claim
there was a mode change.
We can fix both by splitting the CE_VALID and regular code
paths, and making sure only to look at the stat information
in the latter. Furthermore, we push the declaration of our
"struct stat" down into the code paths that actually set it,
so we cannot accidentally access it uninitialized in future
code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-15 06:13:06 +08:00
|
|
|
ce->name, 0);
|
2005-05-28 06:55:55 +08:00
|
|
|
continue;
|
2016-10-24 18:42:19 +08:00
|
|
|
} else if (revs->diffopt.ita_invisible_in_index &&
|
|
|
|
ce_intent_to_add(ce)) {
|
2020-08-08 15:53:23 +08:00
|
|
|
newmode = ce_mode_from_stat(ce, st.st_mode);
|
|
|
|
diff_addremove(&revs->diffopt, '+', newmode,
|
2021-04-26 09:02:56 +08:00
|
|
|
null_oid(), 0, ce->name, 0);
|
2016-10-24 18:42:19 +08:00
|
|
|
continue;
|
2005-05-28 06:55:55 +08:00
|
|
|
}
|
run_diff_files: do not look at uninitialized stat data
If we try to diff an index entry marked CE_VALID (because it
was marked with --assume-unchanged), we do not bother even
running stat() on the file to see if it was removed. This
started long ago with 540e694 (Prevent diff machinery from
examining assume-unchanged entries on worktree, 2009-08-11).
However, the subsequent code may look at our "struct stat"
and expect to find actual data; currently it will find
whatever cruft was left on the stack. This can cause
problems in two situations:
1. We call match_stat_with_submodule with the stat data,
so a submodule may be erroneously marked as changed.
2. If --find-copies-harder is in effect, we pass all
entries, even unchanged ones, to diff_change, so it can
list them as rename/copy sources. Since we found no
change, we assume that function will realize it and not
actually display any diff output. However, we end up
feeding it a bogus mode, leading it to sometimes claim
there was a mode change.
We can fix both by splitting the CE_VALID and regular code
paths, and making sure only to look at the stat information
in the latter. Furthermore, we push the declaration of our
"struct stat" down into the code paths that actually set it,
so we cannot accidentally access it uninitialized in future
code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-15 06:13:06 +08:00
|
|
|
|
|
|
|
changed = match_stat_with_submodule(&revs->diffopt, ce, &st,
|
|
|
|
ce_option, &dirty_submodule);
|
|
|
|
newmode = ce_mode_from_stat(ce, st.st_mode);
|
2005-06-12 11:57:13 +08:00
|
|
|
}
|
run_diff_files: do not look at uninitialized stat data
If we try to diff an index entry marked CE_VALID (because it
was marked with --assume-unchanged), we do not bother even
running stat() on the file to see if it was removed. This
started long ago with 540e694 (Prevent diff machinery from
examining assume-unchanged entries on worktree, 2009-08-11).
However, the subsequent code may look at our "struct stat"
and expect to find actual data; currently it will find
whatever cruft was left on the stack. This can cause
problems in two situations:
1. We call match_stat_with_submodule with the stat data,
so a submodule may be erroneously marked as changed.
2. If --find-copies-harder is in effect, we pass all
entries, even unchanged ones, to diff_change, so it can
list them as rename/copy sources. Since we found no
change, we assume that function will realize it and not
actually display any diff output. However, we end up
feeding it a bogus mode, leading it to sometimes claim
there was a mode change.
We can fix both by splitting the CE_VALID and regular code
paths, and making sure only to look at the stat information
in the latter. Furthermore, we push the declaration of our
"struct stat" down into the code paths that actually set it,
so we cannot accidentally access it uninitialized in future
code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-15 06:13:06 +08:00
|
|
|
|
2010-03-13 05:23:52 +08:00
|
|
|
if (!changed && !dirty_submodule) {
|
2008-03-31 03:39:25 +08:00
|
|
|
ce_mark_uptodate(ce);
|
mark_fsmonitor_valid(): mark the index as changed if needed
Without this bug fix, t7519's four "status doesn't detect unreported
modifications" test cases would fail occasionally (and, oddly enough,
*a lot* more frequently on Windows).
The reason is that these test cases intentionally use the side effect of
`git status` to re-write the index if any updates were detected: they
first clean the worktree, run `git status` to update the index as well
as show the output to the casual reader, then make the worktree dirty
again and expect no changes to reported if running with a mocked
fsmonitor hook.
The problem with this strategy was that the index was written during
said `git status` on the clean worktree for the *wrong* reason: not
because the index was marked as changed (it wasn't), but because the
recorded mtimes were racy with the index' own mtime.
As the mtime granularity on Windows is 100 nanoseconds (see e.g.
https://docs.microsoft.com/en-us/windows/desktop/SysInfo/file-times),
the mtimes of the files are often enough *not* racy with the index', so
that that `git status` call currently does not always update the index
(including the fsmonitor extension), causing the test case to fail.
The obvious fix: if we change *any* index entry's `CE_FSMONITOR_VALID`
flag, we should also mark the index as changed. That will cause the
index to be written upon `git status`, *including* an updated fsmonitor
extension.
Side note: Even though the reader might think that the t7519 issue
should be *much* more prevalent on Linux, given that the ext4 filesystem
(that seems to be used by every Linux distribution) stores mtimes in
nanosecond precision. However, ext4 uses `current_kernel_time()` (see
https://unix.stackexchange.com/questions/11599#comment762968_11599; it
is *amazingly* hard to find any proper source of information about such
ext4 questions) whose accuracy seems to depend on many factors but is
safely worse than the 100-nanosecond granularity of NTFS (again, it is
*horribly* hard to find anything remotely authoritative about this
question). So it seems that the racy index condition that hid the bug
fixed by this patch simply is a lot more likely on Linux than on
Windows. But not impossible ;-)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-24 20:23:48 +08:00
|
|
|
mark_fsmonitor_valid(istate, ce);
|
2017-11-01 02:19:11 +08:00
|
|
|
if (!revs->diffopt.flags.find_copies_harder)
|
2008-03-31 03:39:25 +08:00
|
|
|
continue;
|
|
|
|
}
|
2008-01-15 08:03:17 +08:00
|
|
|
oldmode = ce->ce_mode;
|
2017-05-31 01:30:48 +08:00
|
|
|
old_oid = &ce->oid;
|
2021-04-26 09:02:56 +08:00
|
|
|
new_oid = changed ? null_oid() : &ce->oid;
|
2006-04-22 14:57:45 +08:00
|
|
|
diff_change(&revs->diffopt, oldmode, newmode,
|
2017-05-31 01:30:49 +08:00
|
|
|
old_oid, new_oid,
|
2017-05-31 01:30:48 +08:00
|
|
|
!is_null_oid(old_oid),
|
|
|
|
!is_null_oid(new_oid),
|
2010-01-19 04:26:18 +08:00
|
|
|
ce->name, 0, dirty_submodule);
|
2005-04-28 00:21:00 +08:00
|
|
|
|
2005-05-21 00:54:07 +08:00
|
|
|
}
|
2006-04-22 14:57:45 +08:00
|
|
|
diffcore_std(&revs->diffopt);
|
|
|
|
diff_flush(&revs->diffopt);
|
2018-01-27 20:27:56 +08:00
|
|
|
trace_performance_since(start, "diff-files");
|
2006-04-22 14:57:45 +08:00
|
|
|
return 0;
|
2005-04-28 00:21:00 +08:00
|
|
|
}
|
2005-04-27 00:25:05 +08:00
|
|
|
|
2006-04-22 17:43:00 +08:00
|
|
|
/*
|
|
|
|
* diff-index
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* A file entry went away or appeared */
|
|
|
|
static void diff_index_show_file(struct rev_info *revs,
|
|
|
|
const char *prefix,
|
2013-06-02 23:46:55 +08:00
|
|
|
const struct cache_entry *ce,
|
2017-05-31 01:30:46 +08:00
|
|
|
const struct object_id *oid, int oid_valid,
|
diff: do not use null sha1 as a sentinel value
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 23:03:01 +08:00
|
|
|
unsigned int mode,
|
2010-01-19 04:26:18 +08:00
|
|
|
unsigned dirty_submodule)
|
2006-04-22 17:43:00 +08:00
|
|
|
{
|
2008-01-15 08:03:17 +08:00
|
|
|
diff_addremove(&revs->diffopt, prefix[0], mode,
|
2017-05-31 01:30:47 +08:00
|
|
|
oid, oid_valid, ce->name, dirty_submodule);
|
2006-04-22 17:43:00 +08:00
|
|
|
}
|
|
|
|
|
2021-03-18 05:22:22 +08:00
|
|
|
static int get_stat_data(const struct index_state *istate,
|
|
|
|
const struct cache_entry *ce,
|
2017-05-31 01:30:45 +08:00
|
|
|
const struct object_id **oidp,
|
2006-04-22 17:43:00 +08:00
|
|
|
unsigned int *modep,
|
2010-01-19 04:26:18 +08:00
|
|
|
int cached, int match_missing,
|
2010-01-24 00:37:26 +08:00
|
|
|
unsigned *dirty_submodule, struct diff_options *diffopt)
|
2006-04-22 17:43:00 +08:00
|
|
|
{
|
2017-05-31 01:30:45 +08:00
|
|
|
const struct object_id *oid = &ce->oid;
|
2006-04-22 17:43:00 +08:00
|
|
|
unsigned int mode = ce->ce_mode;
|
|
|
|
|
2009-05-10 05:57:30 +08:00
|
|
|
if (!cached && !ce_uptodate(ce)) {
|
2006-04-22 17:43:00 +08:00
|
|
|
int changed;
|
|
|
|
struct stat st;
|
2021-03-18 05:22:22 +08:00
|
|
|
changed = check_removed(istate, ce, &st);
|
2008-03-31 08:29:48 +08:00
|
|
|
if (changed < 0)
|
|
|
|
return -1;
|
|
|
|
else if (changed) {
|
|
|
|
if (match_missing) {
|
2017-05-31 01:30:45 +08:00
|
|
|
*oidp = oid;
|
2006-04-22 17:43:00 +08:00
|
|
|
*modep = mode;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
2010-03-12 05:50:25 +08:00
|
|
|
changed = match_stat_with_submodule(diffopt, ce, &st,
|
|
|
|
0, dirty_submodule);
|
2006-04-22 17:43:00 +08:00
|
|
|
if (changed) {
|
2007-02-17 14:43:48 +08:00
|
|
|
mode = ce_mode_from_stat(ce, st.st_mode);
|
2021-04-26 09:02:56 +08:00
|
|
|
oid = null_oid();
|
2006-04-22 17:43:00 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-31 01:30:45 +08:00
|
|
|
*oidp = oid;
|
2006-04-22 17:43:00 +08:00
|
|
|
*modep = mode;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-01-12 02:36:42 +08:00
|
|
|
static void show_new_file(struct rev_info *revs,
|
2018-02-15 02:59:38 +08:00
|
|
|
const struct cache_entry *new_file,
|
2006-04-22 17:43:00 +08:00
|
|
|
int cached, int match_missing)
|
|
|
|
{
|
2017-05-31 01:30:45 +08:00
|
|
|
const struct object_id *oid;
|
2006-04-22 17:43:00 +08:00
|
|
|
unsigned int mode;
|
2010-01-19 04:26:18 +08:00
|
|
|
unsigned dirty_submodule = 0;
|
2021-03-18 05:22:22 +08:00
|
|
|
struct index_state *istate = revs->diffopt.repo->index;
|
2006-04-22 17:43:00 +08:00
|
|
|
|
2021-07-14 21:12:35 +08:00
|
|
|
if (new_file && S_ISSPARSEDIR(new_file->ce_mode)) {
|
|
|
|
diff_tree_oid(NULL, &new_file->oid, new_file->name, &revs->diffopt);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2008-03-31 08:29:48 +08:00
|
|
|
/*
|
|
|
|
* New file in the index: it might actually be different in
|
2011-09-21 04:25:57 +08:00
|
|
|
* the working tree.
|
2006-04-22 17:43:00 +08:00
|
|
|
*/
|
2021-03-18 05:22:22 +08:00
|
|
|
if (get_stat_data(istate, new_file, &oid, &mode, cached, match_missing,
|
2010-01-24 00:37:26 +08:00
|
|
|
&dirty_submodule, &revs->diffopt) < 0)
|
2006-04-22 17:43:00 +08:00
|
|
|
return;
|
|
|
|
|
2018-02-15 02:59:38 +08:00
|
|
|
diff_index_show_file(revs, "+", new_file, oid, !is_null_oid(oid), mode, dirty_submodule);
|
2006-04-22 17:43:00 +08:00
|
|
|
}
|
|
|
|
|
2009-01-12 02:36:42 +08:00
|
|
|
static int show_modified(struct rev_info *revs,
|
2018-02-15 02:59:38 +08:00
|
|
|
const struct cache_entry *old_entry,
|
|
|
|
const struct cache_entry *new_entry,
|
2006-04-22 17:43:00 +08:00
|
|
|
int report_missing,
|
|
|
|
int cached, int match_missing)
|
|
|
|
{
|
|
|
|
unsigned int mode, oldmode;
|
2017-05-31 01:30:45 +08:00
|
|
|
const struct object_id *oid;
|
2010-01-19 04:26:18 +08:00
|
|
|
unsigned dirty_submodule = 0;
|
2021-03-18 05:22:22 +08:00
|
|
|
struct index_state *istate = revs->diffopt.repo->index;
|
2006-04-22 17:43:00 +08:00
|
|
|
|
2021-07-14 21:12:35 +08:00
|
|
|
assert(S_ISSPARSEDIR(old_entry->ce_mode) ==
|
|
|
|
S_ISSPARSEDIR(new_entry->ce_mode));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If both are sparse directory entries, then expand the
|
|
|
|
* modifications to the file level. If only one was a sparse
|
|
|
|
* directory, then they appear as an add and delete instead of
|
|
|
|
* a modification.
|
|
|
|
*/
|
|
|
|
if (S_ISSPARSEDIR(new_entry->ce_mode)) {
|
|
|
|
diff_tree_oid(&old_entry->oid, &new_entry->oid, new_entry->name, &revs->diffopt);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-03-18 05:22:22 +08:00
|
|
|
if (get_stat_data(istate, new_entry, &oid, &mode, cached, match_missing,
|
2010-01-24 00:37:26 +08:00
|
|
|
&dirty_submodule, &revs->diffopt) < 0) {
|
2006-04-22 17:43:00 +08:00
|
|
|
if (report_missing)
|
2018-02-15 02:59:38 +08:00
|
|
|
diff_index_show_file(revs, "-", old_entry,
|
|
|
|
&old_entry->oid, 1, old_entry->ce_mode,
|
2016-09-06 04:07:52 +08:00
|
|
|
0);
|
2006-04-22 17:43:00 +08:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2006-09-04 19:38:40 +08:00
|
|
|
if (revs->combine_merges && !cached &&
|
2018-08-29 05:22:48 +08:00
|
|
|
(!oideq(oid, &old_entry->oid) || !oideq(&old_entry->oid, &new_entry->oid))) {
|
2006-09-04 19:38:40 +08:00
|
|
|
struct combine_diff_path *p;
|
2018-02-15 02:59:38 +08:00
|
|
|
int pathlen = ce_namelen(new_entry);
|
2006-09-04 19:38:40 +08:00
|
|
|
|
|
|
|
p = xmalloc(combine_diff_path_size(2, pathlen));
|
|
|
|
p->path = (char *) &p->parent[2];
|
|
|
|
p->next = NULL;
|
2018-02-15 02:59:38 +08:00
|
|
|
memcpy(p->path, new_entry->name, pathlen);
|
2006-09-04 19:38:40 +08:00
|
|
|
p->path[pathlen] = 0;
|
2008-01-15 08:03:17 +08:00
|
|
|
p->mode = mode;
|
2015-03-14 07:39:33 +08:00
|
|
|
oidclr(&p->oid);
|
2006-09-04 19:38:40 +08:00
|
|
|
memset(p->parent, 0, 2 * sizeof(struct combine_diff_parent));
|
|
|
|
p->parent[0].status = DIFF_STATUS_MODIFIED;
|
2018-02-15 02:59:38 +08:00
|
|
|
p->parent[0].mode = new_entry->ce_mode;
|
|
|
|
oidcpy(&p->parent[0].oid, &new_entry->oid);
|
2006-09-04 19:38:40 +08:00
|
|
|
p->parent[1].status = DIFF_STATUS_MODIFIED;
|
2018-02-15 02:59:38 +08:00
|
|
|
p->parent[1].mode = old_entry->ce_mode;
|
|
|
|
oidcpy(&p->parent[1].oid, &old_entry->oid);
|
2020-09-29 19:31:22 +08:00
|
|
|
show_combined_diff(p, 2, revs);
|
2006-09-04 19:38:40 +08:00
|
|
|
free(p);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-02-15 02:59:38 +08:00
|
|
|
oldmode = old_entry->ce_mode;
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
if (mode == oldmode && oideq(oid, &old_entry->oid) && !dirty_submodule &&
|
2017-11-01 02:19:11 +08:00
|
|
|
!revs->diffopt.flags.find_copies_harder)
|
2006-04-22 17:43:00 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
diff_change(&revs->diffopt, oldmode, mode,
|
2018-02-15 02:59:38 +08:00
|
|
|
&old_entry->oid, oid, 1, !is_null_oid(oid),
|
|
|
|
old_entry->name, 0, dirty_submodule);
|
2006-04-22 17:43:00 +08: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 09:27:12 +08: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,
|
2013-06-02 23:46:55 +08:00
|
|
|
const struct cache_entry *idx,
|
|
|
|
const struct cache_entry *tree)
|
2006-04-22 17:43:00 +08:00
|
|
|
{
|
2009-01-12 02:36:42 +08:00
|
|
|
struct rev_info *revs = o->unpack_data;
|
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 09:27:12 +08:00
|
|
|
int match_missing, cached;
|
2006-04-22 18:58:04 +08:00
|
|
|
|
2018-05-26 20:08:43 +08:00
|
|
|
/*
|
|
|
|
* i-t-a entries do not actually exist in the index (if we're
|
|
|
|
* looking at its content)
|
|
|
|
*/
|
|
|
|
if (o->index_only &&
|
|
|
|
revs->diffopt.ita_invisible_in_index &&
|
2016-10-24 18:42:19 +08:00
|
|
|
idx && ce_intent_to_add(idx)) {
|
|
|
|
idx = NULL;
|
|
|
|
if (!tree)
|
|
|
|
return; /* nothing to diff.. */
|
|
|
|
}
|
|
|
|
|
2009-08-11 23:43:59 +08:00
|
|
|
/* if the entry is not checked out, don't examine work tree */
|
2009-08-20 21:46:58 +08:00
|
|
|
cached = o->index_only ||
|
|
|
|
(idx && ((idx->ce_flags & CE_VALID) || ce_skip_worktree(idx)));
|
2020-09-01 04:14:22 +08:00
|
|
|
|
|
|
|
match_missing = revs->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 09:27:12 +08:00
|
|
|
|
|
|
|
if (cached && idx && ce_stage(idx)) {
|
2011-04-23 07:05:58 +08:00
|
|
|
struct diff_filepair *pair;
|
|
|
|
pair = diff_unmerge(&revs->diffopt, idx->name);
|
2011-07-14 12:36:29 +08:00
|
|
|
if (tree)
|
2017-05-31 01:30:50 +08:00
|
|
|
fill_filespec(pair->one, &tree->oid, 1,
|
2016-09-06 04:07:52 +08:00
|
|
|
tree->ce_mode);
|
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 09:27:12 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Something added to the tree?
|
|
|
|
*/
|
|
|
|
if (!tree) {
|
2009-01-12 02:36:42 +08:00
|
|
|
show_new_file(revs, 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 09:27:12 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Something removed from the tree?
|
2006-04-22 18:58:04 +08: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 09:27:12 +08:00
|
|
|
if (!idx) {
|
2022-08-09 03:07:50 +08:00
|
|
|
if (S_ISSPARSEDIR(tree->ce_mode)) {
|
|
|
|
diff_tree_oid(&tree->oid, NULL, tree->name, &revs->diffopt);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-05-31 01:30:46 +08:00
|
|
|
diff_index_show_file(revs, "-", tree, &tree->oid, 1,
|
2016-09-06 04:07:52 +08:00
|
|
|
tree->ce_mode, 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 09:27:12 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Show difference between old and new */
|
2009-01-12 02:36:42 +08:00
|
|
|
show_modified(revs, 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 09:27:12 +08: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.
|
|
|
|
*
|
2009-09-18 13:12:17 +08:00
|
|
|
* We're supposed to advance o->pos to skip what we have already processed.
|
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 09:27:12 +08:00
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*/
|
2013-06-02 23:46:56 +08:00
|
|
|
static int oneway_diff(const struct cache_entry * const *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 09:27:12 +08:00
|
|
|
{
|
2013-06-02 23:46:55 +08:00
|
|
|
const struct cache_entry *idx = src[0];
|
|
|
|
const struct cache_entry *tree = src[1];
|
2009-01-12 02:36:42 +08:00
|
|
|
struct rev_info *revs = o->unpack_data;
|
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 09:27:12 +08: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;
|
|
|
|
|
2018-09-21 23:57:26 +08:00
|
|
|
if (ce_path_match(revs->diffopt.repo->index,
|
|
|
|
idx ? idx : tree,
|
|
|
|
&revs->prune_data, NULL)) {
|
2008-03-07 10:12:28 +08:00
|
|
|
do_oneway_diff(o, idx, tree);
|
2011-06-01 01:06:44 +08:00
|
|
|
if (diff_can_quit_early(&revs->diffopt)) {
|
|
|
|
o->exiting_early = 1;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
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 09:27:12 +08:00
|
|
|
|
2008-03-07 10:12:28 +08: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 09:27:12 +08:00
|
|
|
}
|
|
|
|
|
2011-07-14 09:57:42 +08:00
|
|
|
static int diff_cache(struct rev_info *revs,
|
2017-05-07 06:10:35 +08:00
|
|
|
const struct object_id *tree_oid,
|
2011-07-14 09:57:42 +08:00
|
|
|
const char *tree_name,
|
|
|
|
int cached)
|
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 09:27:12 +08:00
|
|
|
{
|
|
|
|
struct tree *tree;
|
|
|
|
struct tree_desc t;
|
2011-07-14 09:57:42 +08:00
|
|
|
struct unpack_trees_options opts;
|
2006-04-22 17:43:00 +08:00
|
|
|
|
2017-05-07 06:10:37 +08:00
|
|
|
tree = parse_tree_indirect(tree_oid);
|
2006-04-22 17:43:00 +08:00
|
|
|
if (!tree)
|
2011-07-14 09:57:42 +08:00
|
|
|
return error("bad tree object %s",
|
2017-05-07 06:10:35 +08:00
|
|
|
tree_name ? tree_name : oid_to_hex(tree_oid));
|
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 09:27:12 +08:00
|
|
|
memset(&opts, 0, sizeof(opts));
|
|
|
|
opts.head_idx = 1;
|
|
|
|
opts.index_only = cached;
|
2009-05-23 14:14:25 +08:00
|
|
|
opts.diff_index_cached = (cached &&
|
2017-11-01 02:19:11 +08:00
|
|
|
!revs->diffopt.flags.find_copies_harder);
|
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 09:27:12 +08:00
|
|
|
opts.merge = 1;
|
|
|
|
opts.fn = oneway_diff;
|
2009-01-12 02:36:42 +08:00
|
|
|
opts.unpack_data = revs;
|
2018-09-21 23:57:26 +08:00
|
|
|
opts.src_index = revs->diffopt.repo->index;
|
2008-03-07 10:12:28 +08:00
|
|
|
opts.dst_index = NULL;
|
2011-08-30 04:34:08 +08:00
|
|
|
opts.pathspec = &revs->diffopt.pathspec;
|
2012-01-15 18:03:27 +08:00
|
|
|
opts.pathspec->recursive = 1;
|
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 09:27:12 +08:00
|
|
|
|
|
|
|
init_tree_desc(&t, tree->buffer, tree->size);
|
2011-07-14 09:57:42 +08:00
|
|
|
return unpack_trees(1, &t, &opts);
|
|
|
|
}
|
|
|
|
|
2020-09-20 19:22:23 +08:00
|
|
|
void diff_get_merge_base(const struct rev_info *revs, struct object_id *mb)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct commit *mb_child[2] = {0};
|
|
|
|
struct commit_list *merge_bases;
|
|
|
|
|
|
|
|
for (i = 0; i < revs->pending.nr; i++) {
|
|
|
|
struct object *obj = revs->pending.objects[i].item;
|
|
|
|
if (obj->flags)
|
|
|
|
die(_("--merge-base does not work with ranges"));
|
|
|
|
if (obj->type != OBJ_COMMIT)
|
|
|
|
die(_("--merge-base only works with commits"));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This check must go after the for loop above because A...B
|
|
|
|
* ranges produce three pending commits, resulting in a
|
|
|
|
* misleading error message.
|
|
|
|
*/
|
|
|
|
if (revs->pending.nr < 1 || revs->pending.nr > 2)
|
|
|
|
BUG("unexpected revs->pending.nr: %d", revs->pending.nr);
|
|
|
|
|
|
|
|
for (i = 0; i < revs->pending.nr; i++)
|
|
|
|
mb_child[i] = lookup_commit_reference(the_repository, &revs->pending.objects[i].item->oid);
|
|
|
|
if (revs->pending.nr == 1) {
|
|
|
|
struct object_id oid;
|
|
|
|
|
2023-03-28 21:58:46 +08:00
|
|
|
if (repo_get_oid(the_repository, "HEAD", &oid))
|
2020-09-20 19:22:23 +08:00
|
|
|
die(_("unable to get HEAD"));
|
|
|
|
|
|
|
|
mb_child[1] = lookup_commit_reference(the_repository, &oid);
|
|
|
|
}
|
|
|
|
|
|
|
|
merge_bases = repo_get_merge_bases(the_repository, mb_child[0], mb_child[1]);
|
|
|
|
if (!merge_bases)
|
|
|
|
die(_("no merge base found"));
|
|
|
|
if (merge_bases->next)
|
|
|
|
die(_("multiple merge bases found"));
|
|
|
|
|
|
|
|
oidcpy(mb, &merge_bases->item->object.oid);
|
|
|
|
|
|
|
|
free_commit_list(merge_bases);
|
|
|
|
}
|
|
|
|
|
2020-09-20 19:22:22 +08:00
|
|
|
int run_diff_index(struct rev_info *revs, unsigned int option)
|
2011-07-14 09:57:42 +08:00
|
|
|
{
|
|
|
|
struct object_array_entry *ent;
|
2020-09-20 19:22:22 +08:00
|
|
|
int cached = !!(option & DIFF_INDEX_CACHED);
|
2020-09-20 19:22:25 +08:00
|
|
|
int merge_base = !!(option & DIFF_INDEX_MERGE_BASE);
|
|
|
|
struct object_id oid;
|
|
|
|
const char *name;
|
|
|
|
char merge_base_hex[GIT_MAX_HEXSZ + 1];
|
2021-03-18 05:22:21 +08:00
|
|
|
struct index_state *istate = revs->diffopt.repo->index;
|
2011-07-14 09:57:42 +08:00
|
|
|
|
has_uncommitted_changes(): fall back to empty tree
If has_uncommitted_changes() can't resolve HEAD (e.g.,
because it's unborn or corrupt), then we end up calling
run_diff_index() with an empty revs.pending array. This
causes a segfault, as run_diff_index() blindly looks at the
first pending item.
Fixing this raises a question of fault: should
run_diff_index() handle this case, or is the caller wrong to
pass an empty pending list?
Looking at the other callers of run_diff_index(), they
handle this in one of three ways:
- they resolve the object themselves, and avoid doing the
diff if it's not valid
- they resolve the object themselves, and fall back to the
empty tree
- they use setup_revisions(), which will die() if the
object isn't valid
Since this is the only broken caller, that argues that the
fix should go there. Falling back to the empty tree makes
sense here, as we'd claim uncommitted changes if and only if
the index is non-empty. This may be a little funny in the
case of corruption (the corrupt HEAD probably _isn't_
empty), but:
- we don't actually know the reason here that HEAD didn't
resolve (the much more likely case is that we have an
unborn HEAD, in which case the empty tree comparison is
the right thing)
- this matches how other code, like "git diff", behaves
While we're thinking about it, let's add an assertion to
run_diff_index(). It should always be passed a single
object, and as this bug shows, it's easy to get it wrong
(and an assertion is easier to hunt down than a segfault, or
a quietly ignored extra tree).
Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-11 22:14:06 +08:00
|
|
|
if (revs->pending.nr != 1)
|
|
|
|
BUG("run_diff_index must be passed exactly one tree");
|
|
|
|
|
2018-08-18 22:41:22 +08:00
|
|
|
trace_performance_enter();
|
2011-07-14 09:57:42 +08:00
|
|
|
ent = revs->pending.objects;
|
2020-09-20 19:22:25 +08:00
|
|
|
|
2021-03-18 05:22:21 +08:00
|
|
|
refresh_fsmonitor(istate);
|
|
|
|
|
2020-09-20 19:22:25 +08:00
|
|
|
if (merge_base) {
|
|
|
|
diff_get_merge_base(revs, &oid);
|
|
|
|
name = oid_to_hex_r(merge_base_hex, &oid);
|
|
|
|
} else {
|
|
|
|
oidcpy(&oid, &ent->item->oid);
|
|
|
|
name = ent->name;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (diff_cache(revs, &oid, name, cached))
|
2008-02-08 00:39:48 +08:00
|
|
|
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 09:27:12 +08:00
|
|
|
|
2008-08-19 11:08:09 +08:00
|
|
|
diff_set_mnemonic_prefix(&revs->diffopt, "c/", cached ? "i/" : "w/");
|
2019-02-14 13:48:03 +08:00
|
|
|
diffcore_fix_diff_index();
|
2006-04-22 17:43:00 +08:00
|
|
|
diffcore_std(&revs->diffopt);
|
|
|
|
diff_flush(&revs->diffopt);
|
2018-08-18 22:41:22 +08:00
|
|
|
trace_performance_leave("diff-index");
|
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 09:27:12 +08:00
|
|
|
return 0;
|
2006-04-22 17:43:00 +08:00
|
|
|
}
|
2007-01-30 17:11:08 +08:00
|
|
|
|
2017-05-07 06:10:35 +08:00
|
|
|
int do_diff_cache(const struct object_id *tree_oid, struct diff_options *opt)
|
2007-01-30 17:11:08 +08:00
|
|
|
{
|
|
|
|
struct rev_info revs;
|
|
|
|
|
2018-11-10 13:49:04 +08:00
|
|
|
repo_init_revisions(opt->repo, &revs, NULL);
|
2013-07-14 16:35:59 +08:00
|
|
|
copy_pathspec(&revs.prune_data, &opt->pathspec);
|
2020-11-15 02:37:03 +08:00
|
|
|
diff_setup_done(&revs.diffopt);
|
2011-07-14 09:57:42 +08:00
|
|
|
revs.diffopt = *opt;
|
2008-01-20 23:19:56 +08:00
|
|
|
|
2017-05-07 06:10:35 +08:00
|
|
|
if (diff_cache(&revs, tree_oid, NULL, 1))
|
2008-02-08 00:39:48 +08:00
|
|
|
exit(128);
|
2022-04-14 04:01:44 +08:00
|
|
|
release_revisions(&revs);
|
2008-01-20 23:19:56 +08:00
|
|
|
return 0;
|
2007-01-30 17:11:08 +08:00
|
|
|
}
|
2009-02-10 22:30:35 +08:00
|
|
|
|
2018-11-10 13:49:04 +08:00
|
|
|
int index_differs_from(struct repository *r,
|
|
|
|
const char *def, const struct diff_flags *flags,
|
2016-10-24 18:42:21 +08:00
|
|
|
int ita_invisible_in_index)
|
2009-02-10 22:30:35 +08:00
|
|
|
{
|
|
|
|
struct rev_info rev;
|
2010-03-09 14:58:09 +08:00
|
|
|
struct setup_revision_opt opt;
|
2022-04-14 13:56:40 +08:00
|
|
|
unsigned has_changes;
|
2009-02-10 22:30:35 +08:00
|
|
|
|
2018-11-10 13:49:04 +08:00
|
|
|
repo_init_revisions(r, &rev, NULL);
|
2010-03-09 14:58:09 +08:00
|
|
|
memset(&opt, 0, sizeof(opt));
|
|
|
|
opt.def = def;
|
|
|
|
setup_revisions(0, NULL, &rev, &opt);
|
2017-11-01 02:19:11 +08:00
|
|
|
rev.diffopt.flags.quick = 1;
|
|
|
|
rev.diffopt.flags.exit_with_status = 1;
|
2017-11-01 02:19:05 +08:00
|
|
|
if (flags)
|
|
|
|
diff_flags_or(&rev.diffopt.flags, flags);
|
2016-10-24 18:42:21 +08:00
|
|
|
rev.diffopt.ita_invisible_in_index = ita_invisible_in_index;
|
2009-02-10 22:30:35 +08:00
|
|
|
run_diff_index(&rev, 1);
|
2022-04-14 13:56:40 +08:00
|
|
|
has_changes = rev.diffopt.flags.has_changes;
|
revision.[ch]: provide and start using a release_revisions()
The users of the revision.[ch] API's "struct rev_info" are a major
source of memory leaks in the test suite under SANITIZE=leak, which in
turn adds a lot of noise when trying to mark up tests with
"TEST_PASSES_SANITIZE_LEAK=true".
The users of that API are largely one-shot, e.g. "git rev-list" or
"git log", or the "git checkout" and "git stash" being modified here
For these callers freeing the memory is arguably a waste of time, but
in many cases they've actually been trying to free the memory, and
just doing that in a buggy manner.
Let's provide a release_revisions() function for these users, and
start migrating them over per the plan outlined in [1]. Right now this
only handles the "pending" member of the struct, but more will be
added in subsequent commits.
Even though we only clear the "pending" member now, let's not leave a
trap in code like the pre-image of index_differs_from(), where we'd
start doing the wrong thing as soon as the release_revisions() learned
to clear its "diffopt". I.e. we need to call release_revisions() after
we've inspected any state in "struct rev_info".
This leaves in place e.g. clear_pathspec(&rev.prune_data) in
stash_working_tree() in builtin/stash.c, subsequent commits will teach
release_revisions() to free "prune_data" and other members that in
some cases are individually cleared by users of "struct rev_info" by
reaching into its members. Those subsequent commits will remove the
relevant calls to e.g. clear_pathspec().
We avoid amending code in index_differs_from() in diff-lib.c as well
as wt_status_collect_changes_index(), has_unstaged_changes() and
has_uncommitted_changes() in wt-status.c in a way that assumes that we
are already clearing the "diffopt" member. That will be handled in a
subsequent commit.
1. https://lore.kernel.org/git/87a6k8daeu.fsf@evledraar.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-14 04:01:35 +08:00
|
|
|
release_revisions(&rev);
|
2022-04-14 13:56:40 +08:00
|
|
|
return (has_changes != 0);
|
2009-02-10 22:30:35 +08:00
|
|
|
}
|
2020-09-08 15:16:08 +08:00
|
|
|
|
2022-12-13 19:13:48 +08:00
|
|
|
static struct strbuf *idiff_prefix_cb(struct diff_options *opt UNUSED, void *data)
|
2020-09-08 15:16:08 +08:00
|
|
|
{
|
|
|
|
return data;
|
|
|
|
}
|
|
|
|
|
2020-09-08 15:16:09 +08:00
|
|
|
void show_interdiff(const struct object_id *oid1, const struct object_id *oid2,
|
|
|
|
int indent, struct diff_options *diffopt)
|
2020-09-08 15:16:08 +08:00
|
|
|
{
|
|
|
|
struct diff_options opts;
|
|
|
|
struct strbuf prefix = STRBUF_INIT;
|
|
|
|
|
2020-09-08 15:16:09 +08:00
|
|
|
memcpy(&opts, diffopt, sizeof(opts));
|
2020-09-08 15:16:08 +08:00
|
|
|
opts.output_format = DIFF_FORMAT_PATCH;
|
|
|
|
opts.output_prefix = idiff_prefix_cb;
|
|
|
|
strbuf_addchars(&prefix, ' ', indent);
|
|
|
|
opts.output_prefix_data = &prefix;
|
|
|
|
diff_setup_done(&opts);
|
|
|
|
|
2020-09-08 15:16:09 +08:00
|
|
|
diff_tree_oid(oid1, oid2, "", &opts);
|
2020-09-08 15:16:08 +08:00
|
|
|
diffcore_std(&opts);
|
|
|
|
diff_flush(&opts);
|
|
|
|
|
|
|
|
strbuf_release(&prefix);
|
|
|
|
}
|