|
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2005 Junio C Hamano
|
|
|
|
|
*/
|
|
|
|
|
#ifndef DIFF_H
|
|
|
|
|
#define DIFF_H
|
|
|
|
|
|
|
|
|
|
#include "tree-walk.h"
|
|
|
|
|
|
Log message printout cleanups
On Sun, 16 Apr 2006, Junio C Hamano wrote:
>
> In the mid-term, I am hoping we can drop the generate_header()
> callchain _and_ the custom code that formats commit log in-core,
> found in cmd_log_wc().
Ok, this was nastier than expected, just because the dependencies between
the different log-printing stuff were absolutely _everywhere_, but here's
a patch that does exactly that.
The patch is not very easy to read, and the "--patch-with-stat" thing is
still broken (it does not call the "show_log()" thing properly for
merges). That's not a new bug. In the new world order it _should_ do
something like
if (rev->logopt)
show_log(rev, rev->logopt, "---\n");
but it doesn't. I haven't looked at the --with-stat logic, so I left it
alone.
That said, this patch removes more lines than it adds, and in particular,
the "cmd_log_wc()" loop is now a very clean:
while ((commit = get_revision(rev)) != NULL) {
log_tree_commit(rev, commit);
free(commit->buffer);
commit->buffer = NULL;
}
so it doesn't get much prettier than this. All the complexity is entirely
hidden in log-tree.c, and any code that needs to flush the log literally
just needs to do the "if (rev->logopt) show_log(...)" incantation.
I had to make the combined_diff() logic take a "struct rev_info" instead
of just a "struct diff_options", but that part is pretty clean.
This does change "git whatchanged" from using "diff-tree" as the commit
descriptor to "commit", and I changed one of the tests to reflect that new
reality. Otherwise everything still passes, and my other tests look fine
too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
struct rev_info;
|
|
|
|
|
struct diff_options;
|
|
|
|
|
struct diff_queue_struct;
|
|
|
|
|
|
|
|
|
|
typedef void (*change_fn_t)(struct diff_options *options,
|
|
|
|
|
unsigned old_mode, unsigned new_mode,
|
|
|
|
|
const unsigned char *old_sha1,
|
|
|
|
|
const unsigned char *new_sha1,
|
|
|
|
|
const char *fullpath);
|
|
|
|
|
|
|
|
|
|
typedef void (*add_remove_fn_t)(struct diff_options *options,
|
|
|
|
|
int addremove, unsigned mode,
|
|
|
|
|
const unsigned char *sha1,
|
|
|
|
|
const char *fullpath);
|
|
|
|
|
|
|
|
|
|
typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
|
|
|
|
|
struct diff_options *options, void *data);
|
|
|
|
|
|
|
|
|
|
#define DIFF_FORMAT_RAW 0x0001
|
|
|
|
|
#define DIFF_FORMAT_DIFFSTAT 0x0002
|
|
|
|
|
#define DIFF_FORMAT_NUMSTAT 0x0004
|
|
|
|
|
#define DIFF_FORMAT_SUMMARY 0x0008
|
|
|
|
|
#define DIFF_FORMAT_PATCH 0x0010
|
|
|
|
|
#define DIFF_FORMAT_SHORTSTAT 0x0020
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
#define DIFF_FORMAT_DIRSTAT 0x0040
|
|
|
|
|
|
|
|
|
|
/* These override all above */
|
|
|
|
|
#define DIFF_FORMAT_NAME 0x0100
|
|
|
|
|
#define DIFF_FORMAT_NAME_STATUS 0x0200
|
|
|
|
|
#define DIFF_FORMAT_CHECKDIFF 0x0400
|
|
|
|
|
|
|
|
|
|
/* Same as output_format = 0 but we know that -s flag was given
|
|
|
|
|
* and we should not give default value to output_format.
|
|
|
|
|
*/
|
|
|
|
|
#define DIFF_FORMAT_NO_OUTPUT 0x0800
|
|
|
|
|
|
|
|
|
|
#define DIFF_FORMAT_CALLBACK 0x1000
|
|
|
|
|
|
|
|
|
|
#define DIFF_OPT_RECURSIVE (1 << 0)
|
|
|
|
|
#define DIFF_OPT_TREE_IN_RECURSIVE (1 << 1)
|
|
|
|
|
#define DIFF_OPT_BINARY (1 << 2)
|
|
|
|
|
#define DIFF_OPT_TEXT (1 << 3)
|
|
|
|
|
#define DIFF_OPT_FULL_INDEX (1 << 4)
|
|
|
|
|
#define DIFF_OPT_SILENT_ON_REMOVE (1 << 5)
|
|
|
|
|
#define DIFF_OPT_FIND_COPIES_HARDER (1 << 6)
|
|
|
|
|
#define DIFF_OPT_FOLLOW_RENAMES (1 << 7)
|
|
|
|
|
#define DIFF_OPT_COLOR_DIFF (1 << 8)
|
|
|
|
|
#define DIFF_OPT_COLOR_DIFF_WORDS (1 << 9)
|
|
|
|
|
#define DIFF_OPT_HAS_CHANGES (1 << 10)
|
|
|
|
|
#define DIFF_OPT_QUIET (1 << 11)
|
|
|
|
|
#define DIFF_OPT_NO_INDEX (1 << 12)
|
|
|
|
|
#define DIFF_OPT_ALLOW_EXTERNAL (1 << 13)
|
|
|
|
|
#define DIFF_OPT_EXIT_WITH_STATUS (1 << 14)
|
|
|
|
|
#define DIFF_OPT_REVERSE_DIFF (1 << 15)
|
|
|
|
|
#define DIFF_OPT_CHECK_FAILED (1 << 16)
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
#define DIFF_OPT_RELATIVE_NAME (1 << 17)
|
|
|
|
|
#define DIFF_OPT_IGNORE_SUBMODULES (1 << 18)
|
|
|
|
|
#define DIFF_OPT_DIRSTAT_CUMULATIVE (1 << 19)
|
|
|
|
|
#define DIFF_OPT_DIRSTAT_BY_FILE (1 << 20)
|
|
|
|
|
#define DIFF_OPT_ALLOW_TEXTCONV (1 << 21)
|
|
|
|
|
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
|
|
|
|
|
#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
|
|
|
|
|
#define DIFF_OPT_CLR(opts, flag) ((opts)->flags &= ~DIFF_OPT_##flag)
|
|
|
|
|
|
|
|
|
|
struct diff_options {
|
|
|
|
|
const char *filter;
|
|
|
|
|
const char *orderfile;
|
|
|
|
|
const char *pickaxe;
|
|
|
|
|
const char *single_follow;
|
|
|
|
|
const char *a_prefix, *b_prefix;
|
|
|
|
|
unsigned flags;
|
|
|
|
|
int context;
|
|
|
|
|
int interhunkcontext;
|
|
|
|
|
int break_opt;
|
|
|
|
|
int detect_rename;
|
git-diff: squelch "empty" diffs
After starting to edit a working tree file but later when your edit ends
up identical to the original (this can also happen when you ran a
wholesale regexp replace with something like "perl -i" that does not
actually modify many of the paths), "git diff" between the index and the
working tree outputs many "empty" diffs that show "diff --git" headers
and nothing else, because these paths are stat-dirty. While it was a
way to warn the user that the earlier action of the user made the index
ineffective as an optimization mechanism, it was felt too loud for the
purpose of warning even to experienced users, and also resulted in
confusing people new to git.
This replaces the "empty" diffs with a single warning message at the
end. Having many such paths hurts performance, and you can run
"git-update-index --refresh" to update the lstat(2) information recorded
in the index in such a case. "git-status" does so as a side effect, and
that is more familiar to the end-user, so we recommend it to them.
The change affects only "git diff" that outputs patch text, because that
is where the annoyance of too many "empty" diff is most strongly felt,
and because the warning message can be safely ignored by downstream
tools without getting mistaken as part of the patch. For the low-level
"git diff-files" and "git diff-index", the traditional behaviour is
retained.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 years ago
|
|
|
int skip_stat_unmatch;
|
|
|
|
|
int line_termination;
|
|
|
|
|
int output_format;
|
|
|
|
|
int pickaxe_opts;
|
|
|
|
|
int rename_score;
|
|
|
|
|
int rename_limit;
|
|
|
|
|
int warn_on_too_large_rename;
|
Add "--dirstat" for some directory statistics
This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.
What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.
What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.
So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.
This patch shows all of that with "--dirstat". The output can be either
something simple like
commit 81772fe...
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 10 23:57:36 2008 +0100
x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
100.0% arch/x86/mm/
or something much more complex like
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
15.3% fs/
7.6% net/rxrpc/
10.2% security/keys/
where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).
I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.
If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory. That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.
For an example of the cumulative reporting, the above commit becomes
commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date: Thu Feb 7 00:15:26 2008 -0800
Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)
20.5% crypto/
7.6% fs/afs/
7.6% fs/fuse/
7.6% fs/gfs2/
5.1% fs/jffs2/
5.1% fs/nfs/
5.1% fs/nfsd/
7.6% fs/reiserfs/
61.5% fs/
7.6% net/rxrpc/
10.2% security/keys/
in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).
The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)
NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).
Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.
But even for git itself, you can get some fun statistics. Try out
git log --dirstat
and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like
git diff --dirstat v1.5.0..v1.5.4
which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a
git diff --dirstat v2.6.24..v2.6.25-rc1
on the kernel is what I actually wrote this for!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
int dirstat_percent;
|
|
|
|
|
int setup;
|
|
|
|
|
int abbrev;
|
diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
const char *prefix;
|
|
|
|
|
int prefix_length;
|
|
|
|
|
const char *stat_sep;
|
|
|
|
|
long xdl_opts;
|
|
|
|
|
|
|
|
|
|
int stat_width;
|
|
|
|
|
int stat_name_width;
|
|
|
|
|
|
|
|
|
|
/* this is set by diffcore for DIFF_FORMAT_PATCH */
|
|
|
|
|
int found_changes;
|
|
|
|
|
|
|
|
|
|
FILE *file;
|
|
|
|
|
int close_file;
|
|
|
|
|
|
|
|
|
|
int nr_paths;
|
|
|
|
|
const char **paths;
|
|
|
|
|
int *pathlens;
|
|
|
|
|
change_fn_t change;
|
|
|
|
|
add_remove_fn_t add_remove;
|
|
|
|
|
diff_format_fn_t format_callback;
|
|
|
|
|
void *format_callback_data;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum color_diff {
|
|
|
|
|
DIFF_RESET = 0,
|
|
|
|
|
DIFF_PLAIN = 1,
|
|
|
|
|
DIFF_METAINFO = 2,
|
|
|
|
|
DIFF_FRAGINFO = 3,
|
|
|
|
|
DIFF_FILE_OLD = 4,
|
|
|
|
|
DIFF_FILE_NEW = 5,
|
|
|
|
|
DIFF_COMMIT = 6,
|
|
|
|
|
DIFF_WHITESPACE = 7,
|
|
|
|
|
};
|
|
|
|
|
const char *diff_get_color(int diff_use_color, enum color_diff ix);
|
|
|
|
|
#define diff_get_color_opt(o, ix) \
|
|
|
|
|
diff_get_color(DIFF_OPT_TST((o), COLOR_DIFF), ix)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
extern const char mime_boundary_leader[];
|
|
|
|
|
|
|
|
|
|
extern void diff_tree_setup_paths(const char **paths, struct diff_options *);
|
|
|
|
|
extern void diff_tree_release_paths(struct diff_options *);
|
|
|
|
|
extern int diff_tree(struct tree_desc *t1, struct tree_desc *t2,
|
|
|
|
|
const char *base, struct diff_options *opt);
|
|
|
|
|
extern int diff_tree_sha1(const unsigned char *old, const unsigned char *new,
|
|
|
|
|
const char *base, struct diff_options *opt);
|
|
|
|
|
extern int diff_root_tree_sha1(const unsigned char *new, const char *base,
|
|
|
|
|
struct diff_options *opt);
|
|
|
|
|
|
|
|
|
|
struct combine_diff_path {
|
|
|
|
|
struct combine_diff_path *next;
|
|
|
|
|
int len;
|
|
|
|
|
char *path;
|
|
|
|
|
unsigned int mode;
|
|
|
|
|
unsigned char sha1[20];
|
|
|
|
|
struct combine_diff_parent {
|
|
|
|
|
char status;
|
|
|
|
|
unsigned int mode;
|
|
|
|
|
unsigned char sha1[20];
|
|
|
|
|
} parent[FLEX_ARRAY];
|
|
|
|
|
};
|
|
|
|
|
#define combine_diff_path_size(n, l) \
|
|
|
|
|
(sizeof(struct combine_diff_path) + \
|
|
|
|
|
sizeof(struct combine_diff_parent) * (n) + (l) + 1)
|
|
|
|
|
|
Log message printout cleanups
On Sun, 16 Apr 2006, Junio C Hamano wrote:
>
> In the mid-term, I am hoping we can drop the generate_header()
> callchain _and_ the custom code that formats commit log in-core,
> found in cmd_log_wc().
Ok, this was nastier than expected, just because the dependencies between
the different log-printing stuff were absolutely _everywhere_, but here's
a patch that does exactly that.
The patch is not very easy to read, and the "--patch-with-stat" thing is
still broken (it does not call the "show_log()" thing properly for
merges). That's not a new bug. In the new world order it _should_ do
something like
if (rev->logopt)
show_log(rev, rev->logopt, "---\n");
but it doesn't. I haven't looked at the --with-stat logic, so I left it
alone.
That said, this patch removes more lines than it adds, and in particular,
the "cmd_log_wc()" loop is now a very clean:
while ((commit = get_revision(rev)) != NULL) {
log_tree_commit(rev, commit);
free(commit->buffer);
commit->buffer = NULL;
}
so it doesn't get much prettier than this. All the complexity is entirely
hidden in log-tree.c, and any code that needs to flush the log literally
just needs to do the "if (rev->logopt) show_log(...)" incantation.
I had to make the combined_diff() logic take a "struct rev_info" instead
of just a "struct diff_options", but that part is pretty clean.
This does change "git whatchanged" from using "diff-tree" as the commit
descriptor to "commit", and I changed one of the tests to reflect that new
reality. Otherwise everything still passes, and my other tests look fine
too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
extern void show_combined_diff(struct combine_diff_path *elem, int num_parent,
|
|
|
|
|
int dense, struct rev_info *);
|
|
|
|
|
|
|
|
|
|
extern void diff_tree_combined(const unsigned char *sha1, const unsigned char parent[][20], int num_parent, int dense, struct rev_info *rev);
|
|
|
|
|
|
Log message printout cleanups
On Sun, 16 Apr 2006, Junio C Hamano wrote:
>
> In the mid-term, I am hoping we can drop the generate_header()
> callchain _and_ the custom code that formats commit log in-core,
> found in cmd_log_wc().
Ok, this was nastier than expected, just because the dependencies between
the different log-printing stuff were absolutely _everywhere_, but here's
a patch that does exactly that.
The patch is not very easy to read, and the "--patch-with-stat" thing is
still broken (it does not call the "show_log()" thing properly for
merges). That's not a new bug. In the new world order it _should_ do
something like
if (rev->logopt)
show_log(rev, rev->logopt, "---\n");
but it doesn't. I haven't looked at the --with-stat logic, so I left it
alone.
That said, this patch removes more lines than it adds, and in particular,
the "cmd_log_wc()" loop is now a very clean:
while ((commit = get_revision(rev)) != NULL) {
log_tree_commit(rev, commit);
free(commit->buffer);
commit->buffer = NULL;
}
so it doesn't get much prettier than this. All the complexity is entirely
hidden in log-tree.c, and any code that needs to flush the log literally
just needs to do the "if (rev->logopt) show_log(...)" incantation.
I had to make the combined_diff() logic take a "struct rev_info" instead
of just a "struct diff_options", but that part is pretty clean.
This does change "git whatchanged" from using "diff-tree" as the commit
descriptor to "commit", and I changed one of the tests to reflect that new
reality. Otherwise everything still passes, and my other tests look fine
too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
extern void diff_tree_combined_merge(const unsigned char *sha1, int, struct rev_info *);
|
diff-tree -c: show a merge commit a bit more sensibly.
A new option '-c' to diff-tree changes the way a merge commit is
displayed when generating a patch output. It shows a "combined
diff" (hence the option letter 'c'), which looks like this:
$ git-diff-tree --pretty -c -p fec9ebf1 | head -n 18
diff-tree fec9ebf... (from parents)
Merge: 0620db3... 8a263ae...
Author: Junio C Hamano <junkio@cox.net>
Date: Sun Jan 15 22:25:35 2006 -0800
Merge fixes up to GIT 1.1.3
diff --combined describe.c
@@@ +98,7 @@@
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
}
- static void describe(char *arg)
- static void describe(struct commit *cmit, int last_one)
++ static void describe(char *arg, int last_one)
{
+ unsigned char sha1[20];
+ struct commit *cmit;
There are a few things to note about this feature:
- The '-c' option implies '-p'. It also implies '-m' halfway
in the sense that "interesting" merges are shown, but not all
merges.
- When a blob matches one of the parents, we do not show a diff
for that path at all. For a merge commit, this option shows
paths with real file-level merge (aka "interesting things").
- As a concequence of the above, an "uninteresting" merge is
not shown at all. You can use '-m' in addition to '-c' to
show the commit log for such a merge, but there will be no
combined diff output.
- Unlike "gitk", the output is monochrome.
A '-' character in the nth column means the line is from the nth
parent and does not appear in the merge result (i.e. removed
from that parent's version).
A '+' character in the nth column means the line appears in the
merge result, and the nth parent does not have that line
(i.e. added by the merge itself or inherited from another
parent).
The above example output shows that the function signature was
changed from either parents (hence two "-" lines and a "++"
line), and "unsigned char sha1[20]", prefixed by a " +", was
inherited from the first parent.
The code as sent to the list was buggy in few corner cases,
which I have fixed since then.
It does not bother to keep track of and show the line numbers
from parent commits, which it probably should.
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
|
|
|
|
|
void diff_set_mnemonic_prefix(struct diff_options *options, const char *a, const char *b);
|
|
|
|
|
|
|
|
|
|
extern void diff_addremove(struct diff_options *,
|
|
|
|
|
int addremove,
|
|
|
|
|
unsigned mode,
|
|
|
|
|
const unsigned char *sha1,
|
|
|
|
|
const char *fullpath);
|
|
|
|
|
|
|
|
|
|
extern void diff_change(struct diff_options *,
|
|
|
|
|
unsigned mode1, unsigned mode2,
|
|
|
|
|
const unsigned char *sha1,
|
|
|
|
|
const unsigned char *sha2,
|
|
|
|
|
const char *fullpath);
|
|
|
|
|
|
|
|
|
|
extern void diff_unmerge(struct diff_options *,
|
|
|
|
|
const char *path,
|
|
|
|
|
unsigned mode,
|
|
|
|
|
const unsigned char *sha1);
|
|
|
|
|
|
|
|
|
|
#define DIFF_SETUP_REVERSE 1
|
|
|
|
|
#define DIFF_SETUP_USE_CACHE 2
|
|
|
|
|
#define DIFF_SETUP_USE_SIZE_CACHE 4
|
|
|
|
|
|
|
|
|
|
extern int git_diff_basic_config(const char *var, const char *value, void *cb);
|
|
|
|
|
extern int git_diff_ui_config(const char *var, const char *value, void *cb);
|
|
|
|
|
extern int diff_use_color_default;
|
|
|
|
|
extern void diff_setup(struct diff_options *);
|
|
|
|
|
extern int diff_opt_parse(struct diff_options *, const char **, int);
|
|
|
|
|
extern int diff_setup_done(struct diff_options *);
|
|
|
|
|
|
|
|
|
|
#define DIFF_DETECT_RENAME 1
|
|
|
|
|
#define DIFF_DETECT_COPY 2
|
|
|
|
|
|
|
|
|
|
#define DIFF_PICKAXE_ALL 1
|
|
|
|
|
#define DIFF_PICKAXE_REGEX 2
|
[PATCH] Add -B flag to diff-* brothers.
A new diffcore transformation, diffcore-break.c, is introduced.
When the -B flag is given, a patch that represents a complete
rewrite is broken into a deletion followed by a creation. This
makes it easier to review such a complete rewrite patch.
The -B flag takes the same syntax as the -M and -C flags to
specify the minimum amount of non-source material the resulting
file needs to have to be considered a complete rewrite, and
defaults to 99% if not specified.
As the new test t4008-diff-break-rewrite.sh demonstrates, if a
file is a complete rewrite, it is broken into a delete/create
pair, which can further be subjected to the usual rename
detection if -M or -C is used. For example, if file0 gets
completely rewritten to make it as if it were rather based on
file1 which itself disappeared, the following happens:
The original change looks like this:
file0 --> file0' (quite different from file0)
file1 --> /dev/null
After diffcore-break runs, it would become this:
file0 --> /dev/null
/dev/null --> file0'
file1 --> /dev/null
Then diffcore-rename matches them up:
file1 --> file0'
The internal score values are finer grained now. Earlier
maximum of 10000 has been raised to 60000; there is no user
visible changes but there is no reason to waste available bits.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
20 years ago
|
|
|
|
|
|
|
|
extern void diffcore_std(struct diff_options *);
|
|
|
|
|
|
|
|
|
|
#define COMMON_DIFF_OPTIONS_HELP \
|
|
|
|
|
"\ncommon diff options:\n" \
|
|
|
|
|
" -z output diff-raw with lines terminated with NUL.\n" \
|
|
|
|
|
" -p output patch format.\n" \
|
|
|
|
|
" -u synonym for -p.\n" \
|
|
|
|
|
" --patch-with-raw\n" \
|
|
|
|
|
" output both a patch and the diff-raw format.\n" \
|
|
|
|
|
" --stat show diffstat instead of patch.\n" \
|
|
|
|
|
" --numstat show numeric diffstat instead of patch.\n" \
|
|
|
|
|
" --patch-with-stat\n" \
|
|
|
|
|
" output a patch and prepend its diffstat.\n" \
|
|
|
|
|
" --name-only show only names of changed files.\n" \
|
|
|
|
|
" --name-status show names and status of changed files.\n" \
|
|
|
|
|
" --full-index show full object name on index lines.\n" \
|
|
|
|
|
" --abbrev=<n> abbreviate object names in diff-tree header and diff-raw.\n" \
|
|
|
|
|
" -R swap input file pairs.\n" \
|
|
|
|
|
" -B detect complete rewrites.\n" \
|
|
|
|
|
" -M detect renames.\n" \
|
|
|
|
|
" -C detect copies.\n" \
|
|
|
|
|
" --find-copies-harder\n" \
|
|
|
|
|
" try unchanged files as candidate for copy detection.\n" \
|
|
|
|
|
" -l<n> limit rename attempts up to <n> paths.\n" \
|
|
|
|
|
" -O<file> reorder diffs according to the <file>.\n" \
|
|
|
|
|
" -S<string> find filepair whose only one side contains the string.\n" \
|
|
|
|
|
" --pickaxe-all\n" \
|
|
|
|
|
" show all files diff when -S is used and hit is found.\n" \
|
|
|
|
|
" -a --text treat all files as text.\n"
|
|
|
|
|
|
|
|
|
|
extern int diff_queue_is_empty(void);
|
|
|
|
|
extern void diff_flush(struct diff_options*);
|
|
|
|
|
|
|
|
|
|
/* diff-raw status letters */
|
|
|
|
|
#define DIFF_STATUS_ADDED 'A'
|
|
|
|
|
#define DIFF_STATUS_COPIED 'C'
|
|
|
|
|
#define DIFF_STATUS_DELETED 'D'
|
|
|
|
|
#define DIFF_STATUS_MODIFIED 'M'
|
|
|
|
|
#define DIFF_STATUS_RENAMED 'R'
|
|
|
|
|
#define DIFF_STATUS_TYPE_CHANGED 'T'
|
|
|
|
|
#define DIFF_STATUS_UNKNOWN 'X'
|
|
|
|
|
#define DIFF_STATUS_UNMERGED 'U'
|
|
|
|
|
|
|
|
|
|
/* these are not diff-raw status letters proper, but used by
|
|
|
|
|
* diffcore-filter insn to specify additional restrictions.
|
|
|
|
|
*/
|
|
|
|
|
#define DIFF_STATUS_FILTER_AON '*'
|
|
|
|
|
#define DIFF_STATUS_FILTER_BROKEN 'B'
|
|
|
|
|
|
|
|
|
|
extern const char *diff_unique_abbrev(const unsigned char *, int);
|
|
|
|
|
|
|
|
|
|
/* do not report anything on removed paths */
|
|
|
|
|
#define DIFF_SILENT_ON_REMOVED 01
|
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>
17 years ago
|
|
|
/* report racily-clean paths as modified */
|
|
|
|
|
#define DIFF_RACY_IS_MODIFIED 02
|
|
|
|
|
extern int run_diff_files(struct rev_info *revs, unsigned int option);
|
|
|
|
|
extern int run_diff_index(struct rev_info *revs, int cached);
|
|
|
|
|
|
|
|
|
|
extern int do_diff_cache(const unsigned char *, struct diff_options *);
|
|
|
|
|
extern int diff_flush_patch_id(struct diff_options *, unsigned char *);
|
|
|
|
|
|
|
|
|
|
extern int diff_result_code(struct diff_options *, int);
|
|
|
|
|
|
|
|
|
|
extern void diff_no_index(struct rev_info *, int, const char **, int, const char *);
|
|
|
|
|
|
|
|
|
|
#endif /* DIFF_H */
|
