Taking just the diff

Posted Jan 17, 2025 13:54 UTC (Fri) by geert (subscriber, #98403)
In reply to: Taking just the diff by epa
Parent article: The many names of commit 55039832f98c

The former is much more resource-intensive than the latter.

Taking just the diff

Posted Jan 17, 2025 18:16 UTC (Fri) by k3ninho (subscriber, #50375) [Link] (2 responses)

Am I missing something? "Has this patch gone into my branch?" is "Are the changes in this patch in place?"

The diff has end-result line numbers and expected text, you can test "does this line match this patch?" pretty cheaply. If the line number doesn't match up, the unified diff gives you three lines to find so you can check after and before the three lines following. Maybe the lines get split up, but that's a case that a tool can't work out intent.

K3n.

Taking just the diff

Posted Jan 17, 2025 18:47 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

How do you deal with reverts or subsequent edits to the line?

Taking just the diff

Posted Jan 18, 2025 8:41 UTC (Sat) by epa (subscriber, #39769) [Link]

I was thinking that if you applied a given patch, but then made later changes that reverted it or rearranged or even deleted the code, it would still count as having “gone into” that branch. This is similar to checking whether a commit is an ancestor of your branch — it either is or isn’t, for all that later changes might have modified the effect of that commit.

Taking just the diff

Posted Jan 19, 2025 1:59 UTC (Sun) by Heretic_Blacksheep (guest, #169992) [Link]

I'd rather have a family tree that takes a little time to (automatically) trace across all possible branches than no family tree and no easy way to track changes at all. Computers are supposed to be there to do the work for humans with useful and accurate results, not increase manual cognitive load and time needed to sort through disparate not-quite-linked identifiers.

A single unique ancestral id assigned strictly to committed content in which all children and cousin ids including changes to the ancestor are hard linked is preferable to systems where there can be confusion generated as to when, if, and why content may or may not have been integrated into the target work. Effectively what's needed in the kernel is a system in which all changes have such a unique content ID that can be referenced regardless of the sub project. The current system really doesn't appear to work in all cases at the scale the kernel is working at. And the DRM groups need to stop thinking they're independent of "downstream" kernel, when that's obviously a fiction. They're as dependent on kernel features just as the kernel is dependent on their features.