Linus Torvalds [off-list ref] writes:
This uses a simplified libxdiff setup to generate unified diffs _without_
doing fork/execve of GNU "diff".
Good stuff.
Now, in the interest of full disclosure, I should also point out a few
downsides:
- the libxdiff algorithm is different,...
- GNU diff does some nice eye-candy, like trying to figure out what the
last function was, and adding that information to the "@@ .." line.
libxdiff doesn't do that.
That's kind of sad --- Documentation/SubmittingPatches request
people to say "diff -u -p".
- The libxdiff thing has some known deficiencies. In particular, it gets
the "\No newline at end of file" case wrong. So this is currently for
the experimental branch only. I hope Davide will help fix it.
Another thing I noticed is that while libxdiff always shows full
line counts "-n,m +l,k" GNU seems to omit them when it can (m,k
<=1). I am not sure if apply.c is set up to grok what libxdiff
emits correctly. Running t/t1200 shows some obvious examples.
Junio C Hamano [off-list ref] writes:
Linus Torvalds [off-list ref] writes:
quoted
This uses a simplified libxdiff setup to generate unified diffs _without_
doing fork/execve of GNU "diff".
Good stuff.
The reason I like this is because I was thinking about doing
in-core diffs for different purpose when I was driving to work
this morning [*1*] --- to make pickaxe a more useful building
block.
Currently, pickaxe tries to do an exact match to find the case
where a given substring S appears in the version C of the file
but not in the its parent C^n (1 <= n), and then it tells the
diffcore to emit the differences. The user (probably only me on
this list?) is expected to look at the change, make an
intelligent decision to feed a matching substring S' found in
C^n and restart from that commit.
To be a useful "content movement tracker", the process of
finding matching 'old shape' in the previous version and
re-feeding it to pickaxe should be automated if possible, and
in-core diff machinery would be one component to help that.
For example, if I wanted to find when I stole 'ls-files -t'
feature from Cogito, I would first run less ls-files.c; I see
these and am reasonably sure these relate to what I am looking
for:
...
static const char *tag_cached = "";
static const char *tag_unmerged = "";
static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";
static const char *tag_modified = "";
...
So I run:
$ git whatchanged -S'static const char *tag_other = "";
static const char *tag_killed = "";
static const char *tag_modified' -p master -- ls-files.c
which finds:
Author: Junio C Hamano [off-list ref]
Date: Mon Sep 19 15:11:15 2005 -0700
Show modified files in git-ls-files
...
@@ -28,6 +29,7 @@ static const char *tag_unmerged = "";
static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";
+static const char *tag_modified = "";
but that is not what I am interested in; the matching "old
shape" is the version before the tag_modified was added (and it
already had other tag_xxx in there). So with the current
pickaxe, I manually re-run whatchanged starting from the found
commit with modified string like this:
$ git whatchanged -S'static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";' -p $that_commit -- ls-files.c
in order to further drill down.
A truly useful pickaxe should take two line numbers and a
filename (to name the range of lines I am interested in) from
the starting version, notice when that range changes shape, and
after showing the found commit, replace the range with the one
matching from the older commit and continue.
[Footnote]
*1* When you are bogged down in a boring day-job, your brain
tends to try to compensate by spending as much your waking time
as possible on thinking about more interesting and more useful
stuff -- like git ;-).
On Fri, 24 Mar 2006, Junio C Hamano wrote:
Another thing I noticed is that while libxdiff always shows full
line counts "-n,m +l,k" GNU seems to omit them when it can (m,k
<=1). I am not sure if apply.c is set up to grok what libxdiff
emits correctly. Running t/t1200 shows some obvious examples.
Actually, the GNU diff output is the special case, and git-apply handles
it as such.
We could make libxdiff do the same @@-shortening, but it doesn't seem to
be huge deal.
Linus