Re: git-diff-tree rename detection for single file

From: Junio C Hamano <junkio@cox.net>
Date: Oct 19, 2005, 02:45 UTC
Message-ID: <7virvujkcw.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vu0fepn0x.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 14 quoted lines

> David Ho <davidkwho@gmail.com> writes:
>
>> I have a small suggestion to make the diff of a renamed file a bit
>> more meaningful.  I have a file that is renamed-edited and commited. 
>> git-diff-tree -M -p <commit> shows one result and git-diff-tree -M -p
>> <commit> <filename> shows another.  If they both show a rename
>> occurred then I think the single file git-diff-tree will be more
>> useful.
>
> Sorry, this was vetoed by Linus long time ago.  The <filename>
> restricts the paths being passed to the diff machinery upfront,
> so once you say <filename>, the rename detection will see only
> that path and nothing else to compare and guess which other file
> that file in question is a copy of.

Having said that, I think we *could* introduce a new flag to git-diff-* brothers, --late-pathspec, that makes them apply the paths restriction on the output side instead. For obvious reasons, using this flag would not make any sense unless you are using one of -M, -C, or --pickaxe-all.

A related thing I have long longed for is a rename following "git-diff-tree --stdin".

    git-rev-list HEAD | git-diff-tree --stdin -M git-commit.sh

This command line, as everybody hopefully knows, is how "git whatchanged" is implemented internally. If git-diff-tree were taught to follow the rename history, when it hits the boundary that git-commit-script was renamed to git-commit.sh, it could start acting as if the pathspec given were git-commit-script from that point. To see that rename it needs --late-pathspec; the current pathspec filters the input so the above command line would not even care what git-commit-script looked like when the rename happend. It would just tell git-commit.sh appeared from nowhere.

If implemented naively, this rename-following would have funny interactions when it hits a merge commit, so it may probably be harder than it sounds, but this would be a good way to do annotate as well.