On Sun, Apr 15, 2012 at 6:01 PM, David Aguilar <davvid@xxxxxxxxx> wrote: > On Sun, Apr 15, 2012 at 3:20 PM, David Aguilar <davvid@xxxxxxxxx> wrote: >> On Fri, Apr 13, 2012 at 9:36 AM, Tim Henigan <tim.henigan@xxxxxxxxx> wrote: >>> When 'difftool' is called to compare a range of commits that modify >>> more than one file, it opens a separate instance of the diff tool for >>> each file that changed. >>> >>> The new '--dir-diff' option copies all the modified files to a temporary >>> location and runs a directory diff on them in a single instance of the >>> diff tool. >>> >>> Signed-off-by: Tim Henigan <tim.henigan@xxxxxxxxx> >>> --- >>> >>> This replaces v12 of the script that was sent to the list on April 12, 2011. >>> >>> Changes in v13: >>> >>> The 'git diff' command is now called via 'Git->repository->command_oneline' >>> again. We need to run the command in a way that allows @ARGV to be given >>> as a list, rather than a string, to insure that IFS and shell meta- >>> characters are handled properly. Thanks to Junio Hamano for pointing >>> this out [1]. >>> >>> [1]: http://thread.gmane.org/gmane.comp.version-control.git/195326/focus=195353 >> >> Thanks Tim. Sorry for reading this patch out of context and missing >> the obvious point that it needs the diff output to do something useful >> in my last review. >> >> I started testing this patch. I started on the commit before what's >> in pu and then applied this patch: >> >> $ git checkout e9653615fafcbac6109da99fac4fa66b0b432048 >> $ git am difftool.patch >> >> The basics work and I know folks will be really happy when this >> feature lands. Folks have personally asked me for this feature in the >> past. I dig it. I'd also like to help pursue using symlinks sometime >> in the future if that sounds like a reasonable thing to you, but the >> stabilizing the existing implementation is more important right now. >> >> I ran into some issues when trying it against a few random commits. I >> went pretty far back in git's history to see what would happen. >> >> $ git difftool --dir-diff e5b06629de847663aaf0f7daae8de81338da3901 | tail >> Use of uninitialized value $rmode in string eq at >> /home/david/src/git/git-difftool line 96. > > I did some more investigating. I think this happens when the diff > contains detected renames. > > This command made it work: > > $ git difftool --dir-diff --no-renames e5b06629de847663aaf0f7daae8de81338da3901 > > So I think we might need to specify --no-renames when calling git diff --raw. > > xxdiff still gives an error message about "$tmp/left/RelNotes: No such > file or directory" with --no-renames so we may want to touch some > dummy files to make the tools happy. Even better would be to parse the rename line in the diff output and move/symlink the $left path to a location that corresponds to $right. That way the diff tool will show a proper diff for renamed files. One gotcha is that the $left side now has a name that didn't exist at that commit, but it's a nicer experience then getting an empty file. Renaming brings along issues such as file paths becoming directories later in the history, and vice versa. Deleted files may have similar issues to consider (I haven't checked yet). -- David -- To unsubscribe from this list: 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