Jeff King [off-list ref] writes:
What about "git rev-list --pretty=raw"? Is that also porcelain?
Does it re-encode? I didn't check, but ideally it shouldn't (but I do not
care too much either way, to be honest).
I would be curious to hear your take on our failure to respect
--encoding for --pretty=format. Is it a bug to be fixed, or a historical
behavior to be maintained?
I think the fix you outlined was quite reasonable.
On Wed, Nov 12, 2008 at 09:10:26PM -0800, Junio C Hamano wrote:
quoted
What about "git rev-list --pretty=raw"? Is that also porcelain?
Does it re-encode? I didn't check, but ideally it shouldn't (but I do not
care too much either way, to be honest).
Yes, it uses the same pretty_print_commit routine as the "log".
quoted
I would be curious to hear your take on our failure to respect
--encoding for --pretty=format. Is it a bug to be fixed, or a historical
behavior to be maintained?
I think the fix you outlined was quite reasonable.
One thing I just realized that makes it even more reasonable: we
properly munge the encoding header when we _do_ re-encode. So whether we
re-encode or not, you will always get the correct encoding for what is
being output via "%e". Which means that a tool which handles the current
"broken" behavior by re-encoding themselves will trivially handle the
new version: the output will just always be in the --encoding specified
instead of whatever the original encoding was.
And if there are tools that are not looking at the output encoding (and
blindly assuming --encoding works), then they are already broken by the
current behavior, and we will be fixing them.
So I think it is safe to "fix" it as I described.
-Peff