> 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. Sure, arguably most of the complexity comes from the DAG of commits, and the need to distinguish what is local and what is remote, which are not specific to git at all. But its interface makes things unnecessarily more complicated. It seems it grew up from ad-hoc pieces without much planification and it took a long time before it finally started to get more attention. A typical case were the cathedral would have been much better than the bazaar: Research for a minimal set of concepts required to have it work and model commands after it. Yes, it's not trivial and it takes time, but is usually much better in the end. But it's progressing somehow. Some time ago, 'git restore <file>' appeared, to replace the stance 'git checkout -- <file>'. It seems they are also trying to do something with new, hopefully more natural, commands, such as 'git switch' to switch branches. I guess this will benefit the next generations of us, since we have to deal with what's available and works in the meantime (and habits). ;-) And while I'm thinking about it: There is also 'git cherry' to check if some changes are in a branch. It doesn't match on the commit hashes but on the file contents. This is not necessary here because SAs specify the relevant commits per branches, but can be very useful to check that some changes were actually cherry-picked in another branch. -- Olivier Certner
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 karl at denninger.net <mailto:karl at denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4897 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20210225/6f751ef0/attachment.bin>