Am 7/2/2013 0:50, schrieb Alexey Shumkin:
> On Mon, Jul 01, 2013 at 09:00:55AM +0200, Johannes Sixt wrote:
>> Am 6/26/2013 12:19, schrieb Alexey Shumkin:
>>> test_expect_success 'setup complex body' '
>>> git config i18n.commitencoding iso8859-1 &&
>>> echo change2 >foo && git commit -a -F commit-msg &&
>>> head3=$(git rev-parse --verify HEAD) &&
>>> - head3_short=$(git rev-parse --short $head3)
>>> + head3_short=$(git rev-parse --short $head3) &&
>>> + # unset commit encoding config
>>> + # otherwise %e does not print encoding value
>>> + # and following test fails
>> I don't understand this comment. The test vector below already shows that
>> an encoding is printed. Why would this suddenly be different with the
>> updated tests?
> I've changed tests. I've reverted back these ones, and added
> new ones with no i18n.commitEncoding set
>> Assuming that this change doesn't sweep a deeper problem under the rug,
>> it's better to use test_config a few lines earlier.
>>> + git config --unset i18n.commitEncoding
>>> test_format complex-encoding %e <<EOF
>>> commit $head3
>> This is the encoding that I mean.
> These encodings "have appeared" because we've changed 'setup':
> we make commits with i18n.commitEncoding set
I understand why there are additional encoding entries in the expected
output, but we see one encoding entry already listed without this patch.
Why do you say "does not print encoding value" in the comment above?
>>> commit $head2
>>> commit $head1
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html