Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>> Does refresh_cache(REFRESH_QUIET) depend on the porcelain error
>> messages already set? If not another way to fix it may be to delay
>> the call to setup_unpack_trees_porcelain() until it becomes needed.
>>
>> But the patch as posted is certainly an improvement.
>
> Yes, that would work too, I can do it that way if you'd like.
>
> I was trying to keep these fixes as narrow as possible, and resist any
> temptations to re-arrange code so as to avoid allocations, which we can
> often do, but then instead of a 1-line diff it's 10, 50, 100... :)
>
> In this case it'll be somewhere around 10, and just a code-move, so
> maybe that's fine...
The ideal answer I was hoping to hear was
The current implementation of the refresh_cache() function might
not, but there is no guarantee that it will stay so. We may add
more calls that may (or may not) need to access the error
message table before this early return. Setting the porcelain
messages before making any calls to any functions in the API and
unsetting after we are done is a much better code structure.
;-)
