[RFC][Take Four] Show the diff in the commit messages

[Goffredo Baroncelli]

On Thursday 19 July 2007, John Arbash Meinel wrote:
> John Arbash Meinel has voted +0.
> Status is now: Waiting
> Comment:
> I realize I'm coming late to this discussion, but 'commit --show-diff' 
> seems to give a closer meaning than 'commit --diff'.
> 
> +              Option('diff',
> +                     help='Show the diff in the bottom of the 
> editor.'),
> 
> How about:
> 
> Option('diff',
>         help='When no message is supplied, show the diff along with the'
>              ' status summary in the message editor.')
> 

Good point, I didn't considered the combination of the -m and 
the --[show-]diff options

> 
> I would be a lot happier with:
> +        # FIXME: the function show_diff_trees encode the pathname
> +        #        as UTF8. The output of the 
> make_commit_message_template()
> +        #        function is decoded according to the user encoding.
> +        #        So assuming output_encoding = user encoding
> +        #         - if the output_encoding is different from
> +        #        UTF8 the diff body is preserved, but the filename
> +        #        may be not correct
> +        #        - if we set output_encoding=UTF8 and the
> +        #        output_encoding is not UTF8 we have the
> +        #        filepath correct, but the diff body may be not correct
> +
> +        status_tmp.write(stream.getvalue().decode(output_encoding))


Sorry I dont' understand this comment..



> If we could just write the raw stream bytes to the output file, rather 
> than doing any encoding/decoding. I'm guessing it could be done if we 
> changed the layering. But it probably isn't as easy in the current form.

Supposing to share the diff in different environments (unicode+utf8 - 
iso8851-15 / cp850 ), leaving the diff-body as raw-data and the filepath utf8 
encoded may be a good compromise.

But if we use the diff in the same environment where is generated only (as the 
diff used in the commit) and the diff is showed in a editor which is 
_encoding_aware_ I continue to think that the we have to consider the diff 
encoding. 


> This really seems like it is going to puke whenever you have a non-ascii 
> filename modified on Windows. (well, it may not puke since the common 
> encodings are all 8-bit, so the decode() will succeed, it will just give 
> you garbage for the filenames).

Sorry, but I don't understand the last sentence.
If I modify a file in a unix iso8859-15 and if we leave the path UTF8 encoded, 
the editor may show garbage...

> 
> 
> I guess this is better than what we have...

It seems that everybody agree that the diff shall be wrote as raw data.
I am not convinced, but in any case I changed my code....
The down side is that now the edit_commit_message() function and friends
have to handle not only an unicode string, but also a list of strings (unicode 
and not unicode).

Comments are welcome
Goffredo

-- 
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack at inwind.it>
Key fingerprint = CE3C 7E01 6782 30A3 5B87  87C0 BB86 505C 6B2A CFF9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bzr-ci-diff.bundle.diff
Type: text/x-diff
Size: 21795 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070720/33d1aed7/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070720/33d1aed7/attachment-0001.pgp