Behaviour of log --patch --follow

[ekhumoro]

On 13/05/15 22:47, Matt Mackall wrote:
> On Wed, 2015-05-13 at 21:36 +0100, ekhumoro wrote:
>> Hello
>>
>> With mercurial version 3.3.3 and earlier, I could use the following to
>> get a diff for a specific revision that follows history across copies
>> and renames:
>>
>>       hg log --patch --follow -r 233
>
> Can you show us an example of what you mean? As written, the above line
> (with no filenames) says:
>
> 1. show revision 233 only
> 2. show history relative to the working copy
> 3. show a patch for each revision
>
> Up until 3.4, 1 and 2 were basically contradictory and the combination
> was undefined but we didn't report an error. And 3 is independent: it'll
> show the same patches for the same files regardless of --follow. By
> default (without --git), those patches will not report copies and
> renames (because the standard patch format is deficient in this area)..
> but will still show the affected files.
>
> In 3.4, we changed the behavior of the previously nonsensical --follow
> --rev (again, with no file) to the useful "follow history from the
> specified rev (rather than the working copy)" (in other words,
> equivalent to -r ::233 rather than -r ::.).
>
> (All of the above analysis is irrelevant if there's actually a filename
> in your command you're not telling us about.)
>

There's no filename.

I think the issue here is probably my lack of knowledge. Quite a while 
ago, I created an alias which does essentially the same as the command 
above. It solved some problem with renaming (the details of which 
completely escape me now), and I have been using it regularly ever 
since. The alias is:

     fdiff = log --follow --patch

Which I currently use like this:

     hg fdiff -r 233

to see a diff of all the changes made to all the files for a specific 
revision. Am I wrong to assume that --follow could have ever made any 
useful difference for this use case?