Why not filename and line number? [LWN.net]

Why not filename and line number?

Posted Oct 1, 2010 15:12 UTC (Fri) by epa (subscriber, #39769)
In reply to: Why not filename and line number? by intgr
Parent article: Organizing kernel messages

If adding a number to a format string - which does not change the line number of any other piece of code, does not move any code around, and does not add or remove files - causes a merge conflict, then your merge algorithm needs fixing. I don't think git's merging is that bad. On the contrary, a single patch to change some strings should be easy for everyone to merge and doesn't require any manual attention or conflict resolution (which would, however, be needed if the patch changed any actual code).

to post comments

Why not filename and line number?

Posted Oct 1, 2010 16:32 UTC (Fri) by intgr (subscriber, #39733) [Link]

> a single patch to change some strings should be easy for everyone to merge

A _single_ patch is not merged in isolation. That doesn't even make sense. A merge, by definition, can only happen when two patches change the tree from a common ancestor state in different ways. A merge conflict occurs when these two changesets touch the same area of code in different ways.

And git merge doesn't try to be clever. It doesn't understand C. It looks at which lines changed and which didn't, and does a 3-way merge. Resolving merge conflicts requires knowledge of what the code actually does.

So, the printk patch will conflict with every _other_ patch that touches printk lines -- or lines adjacent to a printk -- it's as simple as that.

git merge also obviously cannot assign numbers to printk messages for printk's that were _added_ by other merged patches, so that's another source of headaches.

And can you imagine how many changesets touch printk lines in each kernel release?