threads / discuss / 500

Version of dirdiff to display diffs between git trees

Subject: Version of dirdiff to display diffs between git trees

## tl;dr

5 messages between May 6, 2005 and May 7, 2005.

replies: 4people: 3as markdown or json

Paul Mackerras· May 6, 2005, 13:18 UTC · lore

I have adapted my "dirdiff" program to be able to display differences between git trees (without checking them out). It can display the differences between up to 5 trees, each of which can be either a git tree (identified by a tree id, a commit id or a tag) or the working directory.

The main window summarizes which files have changed. Double-clicking on a file name pops up a diff viewer window which displays the differences between the different versions of the file in a color-coded unidiff format. I find it useful to copy .git/HEAD to .git/OLD_HEAD before doing an update on my linux-2.6 repository, and then after the update do

	girdiff OLD_HEAD HEAD

to see what has changed. With the file list I can easily skip over files that I'm not interested in and then use the diff viewer to look at changes to files that I do care about.

I have called this version "girdiff" to distinguish it from my normal dirdiff releases. It is available at:

	http://ozlabs.org/~paulus/girdiff

If invoked as girdiff, or if invoked as dirdiff and the -g flag is given, it will interpret its arguments as git trees rather than directory or file names. As a special case, the working directory is indicated by ".".

This is still under development and there are probably bugs - let me know if you find any.

Paul.
Linus Torvalds· May 6, 2005, 16:19 UTC · re: Paul Mackerras · lore

Re: Version of dirdiff to display diffs between git trees

On Fri, 6 May 2005, Paul Mackerras wrote:
Show 6 quoted lines
> The main window summarizes which files have changed.  Double-clicking
> on a file name pops up a diff viewer window which displays the
> differences between the different versions of the file in a
> color-coded unidiff format.  I find it useful to copy .git/HEAD to
> .git/OLD_HEAD before doing an update on my linux-2.6 repository, and
> then after the update do

If you use git-pull-script, it does this for you (except it calls it ORIG_HEAD), and you can just do

	git-diff-tree -p ORIG_HEAD HEAD

to see the changes. In fact git-pull-script will do that for you, and output the diffstat of it.

Having the original head is also nice for when you decide that the other side has had a few too many drugs, in which case you just do

	cat .git/ORIG_HEAD > .git/HEAD
	git-read-tree -m HEAD
	git-checkout-cache -f -a
	git-update-cache --refresh
and you're back to your original head (the above is basically "unpull").
		Linus
Krzysztof Halasa· May 6, 2005, 18:53 UTC · re: Linus Torvalds · lore

Re: Version of dirdiff to display diffs between git trees

Linus Torvalds <torvalds@osdl.org> writes:
Show 6 quoted lines
> 	cat .git/ORIG_HEAD > .git/HEAD
> 	git-read-tree -m HEAD
> 	git-checkout-cache -f -a
> 	git-update-cache --refresh
>
> and you're back to your original head (the above is basically "unpull").

So, is "git-read-tree -m HEAD" actually equivalent to "git-read-tree HEAD" and does it simply write complete index (ignoring the old one) corresponding to given HEAD?

-- 
Krzysztof Halasa
Linus Torvalds· May 6, 2005, 19:07 UTC · re: Krzysztof Halasa · lore

Re: Version of dirdiff to display diffs between git trees

On Fri, 6 May 2005, Krzysztof Halasa wrote:
Show 13 quoted lines
>
> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > 	cat .git/ORIG_HEAD > .git/HEAD
> > 	git-read-tree -m HEAD
> > 	git-checkout-cache -f -a
> > 	git-update-cache --refresh
> >
> > and you're back to your original head (the above is basically "unpull").
> 
> So, is "git-read-tree -m HEAD" actually equivalent to "git-read-tree HEAD"
> and does it simply write complete index (ignoring the old one)
> corresponding to given HEAD?

Yes, "git-read-tree -m HEAD" is 100% equivalent to the version without "-m" except: that it reads the old index file, and picks up the file stat information from there if the name/SHA1 pair matches.

This has two implications:
 - "git-read-tree -m HEAD" is a lot better than the non "-m" version, 
   since it means that if most of the files are unchanged between the new
   and the old tree, _most_ of the index is still up-to-date.
   You still need to do "git-update-cache --refresh" to make sure the 
   index is fully up-to-date, but now the refresh has to do a _lot_ less.
 - If your old index file has crap in it, it won't work. If you have a 
   corrupt index file, you can't use "-m". And in particular, if the merge 
   _failed_ and you have unmerged entries in your index file, you can't
   use "-m" (I might change that, and let the single-merge case just 
   ignore unmerged entries).

So the rule is: normally you probably want to use "-m", but if you want to start from a totally clean slate because something went wrong, you should skip the "-m" which then does the "reset the whole index" without the merge of the old index information.

(Also, if the new tree you're reading is totally different from the old one, or you don't have anything checked out, you're better off without the "-m", since it will just add overhead for no gain).

			Linus
Paul Mackerras· May 7, 2005, 00:01 UTC · re: Linus Torvalds · lore

Re: Version of dirdiff to display diffs between git trees

Linus Torvalds writes:
> If you use git-pull-script, it does this for you (except it calls it
OK, cool
Show 6 quoted lines
> ORIG_HEAD), and you can just do
> 
> 	git-diff-tree -p ORIG_HEAD HEAD
> 
> to see the changes. In fact git-pull-script will do that for you, and 
> output the diffstat of it.

Yes, girdiff with two trees is mostly equivalent to git-diff-tree, except that I find the girdiff/dirdiff display much easier to nagivate and parse than a patch viewed in an xterm with less. (I say "mostly equivalent" because if neither tree is the ancestor of the other, girdiff looks at the common ancestor to get an idea of which tree has the more recent version of each file that differs, and colors that one green and the other red, which is extra information that git-diff-tree doesn't give you.)

Similarly, girdiff with a tree and "." is equivalent to git-diff-cache.

Girdiff also has the new dirdiff features of being able to expand the displayed context for a hunk, to move changed lines up and down within a hunk (provided the movement doesn't change the meaning of the diff), and to split context lines into identical -/+ lines (which, together with being able to move -/+ lines makes it possible to rearrange a diff to make it more understandable).

If the working directory is one of the trees being diffed, you can select parts of the diff for a file to be applied to the working directory file. (You can't apply changes to a git tree, of course, because it's immutable.) You can also select parts of the diff for a file and generate a patch embodying just the selected changes.

Next I want to do a commit viewer with the ability to display the differences between arbitrary points in the commit tree using girdiff.

Paul.

← back to recent threads