On 2/25/2021 04:30, Olivier Certner wrote:
Neither command is what I'd call 'intuitive', so it would have taken me a long time to find either of them. I cut and pasted the 'git branch' command and it took me a moment to realize what that meant. Never ran "grep -l" on a pipe, I guess.You made me laugh! Apart from relatively simple commands, git's interface is far from intuitive. That's the reason why I regret that it became the hugely dominant DVCS.
Regression doesn't have to come to a project, but if the tools you choose do things like this then you have to work around them as a project to avoid the issue, and that might wind up being somewhat of a PITA.
This specific issue is IMHO quite severe in terms of operational impact. I track -STABLE but don't load "new things" all the time. For security-related things it's more important to know if I've got something out there in a specific instance where it may apply (and not care in others where it doesn't; aka the recent Xen thing if you're not using Xen.) Otherwise if everything is running as it should do I wish to risk introducing bugs along with improvements? If not in a security-related context, frequently not.
Well, this used to be easy. Is your "uname" r-number HIGHER than the "when fixed" revision? You're good. Now, nope. Now I have to go dig source to know because there is no longer a "revision number" that monotonically increments with each commit so there is no longer a way to have a "point in time" view of the source, as-committed, for a given checked-out version.
IMHO that's a fairly serious regression for the person responsible for keeping security-related things up to date and something the project should find a way to fix before rolling the next -RELEASE. (Yeah, I know that's almost-certain to not happen but it's not like this issue wasn't known since moving things over to git.)
-- Karl Denninger [email protected] <mailto:[email protected]> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
