Version of dirdiff to display diffs between git trees

Version of dirdiff to display diffs between git trees

[Paul Mackerras]

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.

Re: Version of dirdiff to display diffs between git trees

[Linus Torvalds]

On Fri, 6 May 2005, Paul Mackerras wrote:
> 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

Re: Version of dirdiff to display diffs between git trees

[Krzysztof Halasa]

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?
-- 
Krzysztof Halasa

Re: Version of dirdiff to display diffs between git trees

[Linus Torvalds]

On Fri, 6 May 2005, Krzysztof Halasa wrote:
>
> 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

Re: Version of dirdiff to display diffs between git trees

[Paul Mackerras]

Linus Torvalds writes:

> If you use git-pull-script, it does this for you (except it calls it

OK, cool

> 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.