Derrick Stolee <stolee@xxxxxxxxx> writes: > ... but the negation and OR condition made me need to pause and > think about it, while the positive of "does it have a parent and > a second parent?" was something that flowed naturally when I read > it. Yeah, that I 100% agree with. If it were if (!(c->parent && c->parent->next)) handle_ordinary_commit(); else handle_merge_commit(); that would have been very easy to grok. I do not have a strong preference between that and if (c->parent && c->parent->next) handle_merge_commit(); else handle_ordinary_commit(); myself, but I always felt that handling ordinary commits was the primary thing in this code path, which made me react to the swapping of orders of these two calls. > Definitely a taste thing, so I could see you wanting to skip this > one on a pure "don't touch what's not broken" policy. True, too, but the code that fails to be in a readable shape too falls into the "broken" category, so in that sense I do not mind queuing the patch, either (and indeed tonight's 'seen' will include this step in the topic). Thanks.
