Re: Use a *real* built-in diff generator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <junkio@xxxxxxx> writes:

> Linus Torvalds <torvalds@xxxxxxxx> writes:
>
>> 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 <junkio@xxxxxxx>
        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 ;-).

-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]