"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > An example semantic patch looks like this: > > @@ > expression E1; > @@ > - is_null_sha1(E1.hash) > + is_null_oid(&E1) > > @@ > expression E1; > @@ > - is_null_sha1(E1->hash) > + is_null_oid(E1) > > This does what you think it does: transforms calls to is_null_sha1 that > use the struct object_id hash member into calls to is_null_oid. > > I'd like to use this for some of the struct object_id work if others > think this is a good idea. I feel it's likely to reduce the reviewing > overhead and allow people to better reason about the quality and > behavior of the sent patches. Of course, I would still review the > patches manually for errors and improvements, and would still accept > responsibility for the content of the patches. Is the plan for such a "refactor" patch to compose such a series as two patch series: [1/2] automatic refactor which gives the "semantic patch" in the proposed log message as part of its description, and the automated result (with possible misconversions that may have come from bugs in the automated tools), with a separate [2/2] manual fixups that corrects what was misconverted and what was missed? As long as [2/2] can be kept to the minimum (and an automated tool that is worth using should make it so), I think that is a good way forward. Another possibility would be to send the end-result as a single patch, with description on the manual fixups in the proposed log message, but it would be a lot more work to generate and review such a patch, I would think. > If there's interest, I can send a patch with a set of basic object_id > transforms to make it easier for others to make those changes when > they're doing work elsewhere in the codebase. > > [0] http://coccinelle.lip6.fr/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html