freebsd stable - Feb 2021 - How do I know if my 13-stable has security patches?

Thanks, Olivier, for the quick response. Now I don't have to do a system
build!

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.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman at gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


On Wed, Feb 24, 2021 at 10:06 AM Olivier Certner <olivier.freebsd at
free.fr>
wrote:
> Hi,
>
> In your base git repository, type:
> git rev-list <uname_hash> | grep -lF <searched_hash>
>
> This outputs something ("(standard input)") iff you have it in.
>
> In order to limit the search time in case of a false result, you'd
better
> pass
> the --since=<oldest_date> to git rev-list.
>
> There is an alternative if you have a branch pointing to your uname hash:
> git branch --contains <searched_hash> | grep -lF <your_branch>
>
> Regards.
>
> --
> Olivier Certner
>
>
>

> 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