Junio C Hamano wrote:
Show 14 quoted lines
>>The problem is that if sha1 and sha2 correspond to very >>"distant" revision the output of git-diff-tree can be very >>long and also usless as long as I stop searching at first >>match. > > >Perhaps > > $ git-diff-tree -r --name-status --diff-filter=AD sha1 sha2 > >would help you somewhat? This would not make the diff >generation part quicker, but at least you do not have to parse >other types of changes. >
Thanks Junio,
as you said, the speed is almost the same but your way is clearly better.
I have pushed the change.
P.S.: Could be interesting something like?:
git-diff-tree -r --name-status --diff-filter=^M sha1 sha2-------------------
Show 5 quoted lines
>Dscho says: > >if you want to know if tree1 and tree2 have *exactly* the same files, you >only have to compare the sha1 of the two trees. If they are equal you are >virtually guaranteed that the two trees contain the same files.
I have impemented a tree viewer inside qgit. Tree view is updated when user browses through revisions.
Loading the file names of a given tree, altough only for the open directories, is an expensive operation. So I added a little "same files" test to skip tree reloading.
With "same files" I mean that the file list is the same bewteen tree1 and tree1, _not_ that the files content are the same. As example, if tree1 is parent of tree2 (and tree2 is not a merge) and the revision between the two only modified files (git-diff-tree status is M), in my test tree1 and tree2 have the same files, also if sha's are, of course, different.
Put in other way, two trees have the "same files" if I don't have to repaint the tree view window.
Marco
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
