Am 12.02.2018 um 22:48 schrieb Junio C Hamano:
> René Scharfe <l....@web.de> writes:
>
>> Am 12.02.2018 um 22:04 schrieb Junio C Hamano:
>>> Stefan Beller <sbel...@google.com> writes:
>>>
>>>> I thought it may be a helpful
>>>> for merging this series with the rest of the evolved code base which
>>>> may make use of one of the converted functions. So instead of fixing
>>>> that new instance manually, cocinelle could do that instead.
>>>
>>> Having the .cocci used for the conversion *somewhere* would indeed
>>> be helpful, as it allows me to (1) try reproducing this patch by
>>> somebody else using the file and following the steps in order to
>>> audit this patch and (2) catch new places that need to be migrated
>>> in in-flight topics.
>>>
>>> But placing it in contrib/coccinelle/ has other side effects.
>>
>> Running "make coccicheck" takes longer. What other downsides are
>> there?
>
> Once the global variable packed_git has been migrated out of
> existence, no new code that relies on it would be referring to that
> global variable. If coccicheck finds something, the suggested rewrite
> would be turning an unrelated packed_git (which may not even be the
> right type) to a reference to a field in a global variable, that
> would certainly be wrong.
Ugh, yes. The semantic patch in question doesn't contain any type
information. I don't know how to match a variable by name *and* type.
Here's the closest I can come up with to a safe and complete
transformation, but it only handles assignments:
@@
struct packed_git *A;
identifier B = packed_git;
@@
- A = B
+ A = the_repository->objects.packed_git
Seeing the many for loops, I'm tempted to suggest adding a
for_each_packed_git macro to hide the global variable and thus reduce
the number of places to change at cutover. Coccinelle doesn't seem
to like them, though.
A short semantic patch with a limited time of usefulness and possible
side-effects can easily be included in a commit message, of course..
René
