Re: git and the loss of revision numbers
On Mon, 2020-12-28 at 19:38:05 -0500, monochrome wrote: what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src this is needed often when it blows up for someone tracking current You need to fetch the git notes, then you can grep them for the SVN rev you're looking for. $ git fetch origin "refs/notes/*:refs/notes/*" && git fetch $ git checkout `git log --format=%h --notes --grep='revision=367627$' main` It's git commit 9aa6d792b549 for reference. On 12/28/20 11:27 AM, Ed Maste wrote: On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 3cc0c0d66a0-c255241(main)-dirty: ^ This is an incremental counter of commits Also, uqs@ recently fixed an issue in newvers.sh (including the final, non-updating svn revision) and reordered the information. An example of the new format: main-c255126-gb81783dc98e6-dirty \ \ \\ \ \ \ local modifications \ \hash \ commit count branch Note, the `g` in there is by design, it's the format that git-describe will barf out. hth Uli ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On Mon, 2020-12-28 at 17:06:26 -0800, David Wolfskill wrote:
On Mon, Dec 28, 2020 at 04:56:39PM -0800, John-Mark Gurney wrote:
monochrome wrote this message on Mon, Dec 28, 2020 at 19:38 -0500:
> what would be the git command for reverting source to a previous version
> using these numbers? for example, with svn and old numbers:
> svnlite update -r367627 /usr/src
>
> this is needed often when it blows up for someone tracking current
Get the hash from a commit number:
$git rev-list --reverse HEAD | tail -n +255241 | head -n 1
3cc0c0d66a065554459bd2f9b4f80cc07426464a
so:
git checkout $(git rev-list --reverse HEAD | tail -n +255240 | head -n 1)
Or save a process:
git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}'
3cc0c0d66a065554459bd2f9b4f80cc07426464a
(And thus:
git checkout $(git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}')
Could also pass the number to awk via the "-v var=value" command-line.)
Counting commits will not get you to SVN revision 12345, you need to
look at the git notes, they are there for that exact reason.
(fun fact, r12345 isn't actually on the main branch, so don't try with
that one)
% git log --oneline -n1 --notes --grep='revision=12346$' main
df4f0253cd89 Use NO_MTREE, not !USE_X11 && !USE_IMAKE, to determine package
args. NO_MTREE should work as advertised (for both direct installation and pkg_add) now.
Notes:
svn path=/head/; revision=12346
So df4f0253cd89 is the corresponding git commit to your SVN r12346
hth
Uli
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On 12/29/20 7:11 AM, monochrome wrote: > ok, this appears to be what I was looking for > > example: > git reset --hard f20c0e331 > then: > git pull --ff-only > is again able to update as normal > > I should point out also that this is from the point of view of any > random person just building freebsd from source, not a developer, so > there are no local changes. Though it does blow away changes to the conf > file, that's a lesser issue to deal with. One other thing to consider is that if you are trying to track down a regression, you can use 'git bisect' to do this and it will do the binary search for you. In the case of searching for a regression, you will be better served by that tool than trying to use 'git reset --hard' directly. The other approach you can use to avoid having to look up hashes would be to create your own local tags each time you update. Then you can easily go back to that tag by name instead of having to look up the hash. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On 29/12/20 18:38, Andriy Gapon wrote: On 2020-12-29 17:11, monochrome wrote: ok, this appears to be what I was looking for example: git reset --hard f20c0e331 then: git pull --ff-only is again able to update as normal I should point out also that this is from the point of view of any random person just building freebsd from source, not a developer, so there are no local changes. Though it does blow away changes to the conf file, that's a lesser issue to deal with. git stash [save] and git stash pop can be used to try[*] to preserve minor local changes. [*] there can be merge conflicts after stash pop if the same file(s) are changed upstream as well. Anyone who already uses git knows this, probably, but for the sake of people who have no experience with it "git stash pop" behaviour can be startling(at least, it was for me when I first used it): after a "git stash pop" which causes conflicts git will set up to actaully create a commit in the branch with the resolved conflict, which (usually for me) is not what one really wants. I usually just do "git reset; git stash drop" in this case and then fix conflicts, to leave me with no extra commits, the changes in my checkout as I want them and no stashed ones (gt does not remove the stash until you commit the resolved changes, which, as I said is not what I want to do usually) I hope I clearly explained this, and if this was obvious to everyone, sorry for the noise! -- Guido Falsi ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On 2020-12-29 17:11, monochrome wrote: > ok, this appears to be what I was looking for > > example: > git reset --hard f20c0e331 > then: > git pull --ff-only > is again able to update as normal > > I should point out also that this is from the point of view of any > random person just building freebsd from source, not a developer, so > there are no local changes. Though it does blow away changes to the conf > file, that's a lesser issue to deal with. git stash [save] and git stash pop can be used to try[*] to preserve minor local changes. [*] there can be merge conflicts after stash pop if the same file(s) are changed upstream as well. -- Andriy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
monochrome: > the g is also in the uname output: > > main-c421-gf20c0e331-dirty It's the brand new format: -c-g[-dirty] https://cgit.freebsd.org/src/commit/sys/conf/newvers.sh?id=8d405efd73d3991fe1647f91a2b7c9989dd5f18f -- Christian "naddy" Weisgerber na...@mips.inka.de ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
ok, this appears to be what I was looking for example: git reset --hard f20c0e331 then: git pull --ff-only is again able to update as normal I should point out also that this is from the point of view of any random person just building freebsd from source, not a developer, so there are no local changes. Though it does blow away changes to the conf file, that's a lesser issue to deal with. thanks! On 12/29/20 9:37 AM, Andriy Gapon wrote: On 2020-12-29 02:56, Pete Wright wrote: On 12/28/20 4:38 PM, monochrome wrote: what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src I will generally just checkout the short git hash like so in my local checkout: $ git checkout gb81783dc98e6 you can quickly get the hashes by running "git log" from your checkout. I think that git checkout is a wrong tool here. I personally would use git reset --hard . Note that that command would also revert any local uncommitted changes as well! My view of the difference between the commands: - checkout: stage[*] a change that would modify the current state of the branch to the selected commit's state - reset: change the current branch (its head) to point to the selected commit [*] by stage I mean modify the working copy and the index. That is, if after git checkout you would run git commit then you would commit a change that reverts the current branch to the selected point. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On 2020-12-29 02:56, Pete Wright wrote: > > On 12/28/20 4:38 PM, monochrome wrote: >> what would be the git command for reverting source to a previous >> version using these numbers? for example, with svn and old numbers: >> svnlite update -r367627 /usr/src >> > I will generally just checkout the short git hash like so in my local > checkout: > $ git checkout gb81783dc98e6 > > you can quickly get the hashes by running "git log" from your checkout. I think that git checkout is a wrong tool here. I personally would use git reset --hard . Note that that command would also revert any local uncommitted changes as well! My view of the difference between the commands: - checkout: stage[*] a change that would modify the current state of the branch to the selected commit's state - reset: change the current branch (its head) to point to the selected commit [*] by stage I mean modify the working copy and the index. That is, if after git checkout you would run git commit then you would commit a change that reverts the current branch to the selected point. -- Andriy ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On 12/29/20 7:15 AM, Kristof Provost wrote: On 29 Dec 2020, at 4:33, monochrome wrote: sry forgot details: source tree @ ead01bfe8 git -C /usr/src checkout gf20c0e331 error: pathspec 'gf20c0e331' did not match any file(s) known to git what is the 'g' for? That would have been a typo, I think. the g is also in the uname output: main-c421-gf20c0e331-dirty git -C /usr/src checkout f20c0e331 M sys/amd64/conf/GENERIC HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root bundle yet I don't see any indication that anything changed, and now it wont update at all: If something went wrong there’d be error output. Git is *fast*, which can lead you to assume it’s not done anything when it has in fact done exactly what you asked. You should be on that commit now. that was the full output, and nothing showing that it changed/reverted any files, and the contents of /usr/src/.git/refs/heads/main is still ead01bfe8618e879b3b23c6cf9f026eadcc7d2b3 is there another place to find the current revision of the source? the point here is to revert to a previous known working state of the source tree exactly like svnlite update -rXX /usr/src used to do, and svn could then update from that point again with the same command used to do regular update: svnlite update /usr/src git -C /usr/src pull --ff-only You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull Yes, you can’t merge to a detached head. Return to your original branch (presumably git checkout main) and then pull. Regards, Kristof ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" the point is, there are only 4 commands we need to do this entire thing and it should be ironed out: 1. initially download the source tree 2. get the current local source tree revision 3. update the local source tree 4. revert local source tree to previous state thanks for your input! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On 29 Dec 2020, at 4:33, monochrome wrote: sry forgot details: source tree @ ead01bfe8 git -C /usr/src checkout gf20c0e331 error: pathspec 'gf20c0e331' did not match any file(s) known to git what is the 'g' for? That would have been a typo, I think. git -C /usr/src checkout f20c0e331 M sys/amd64/conf/GENERIC HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root bundle yet I don't see any indication that anything changed, and now it wont update at all: If something went wrong there’d be error output. Git is *fast*, which can lead you to assume it’s not done anything when it has in fact done exactly what you asked. You should be on that commit now. git -C /usr/src pull --ff-only You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull Yes, you can’t merge to a detached head. Return to your original branch (presumably git checkout main) and then pull. Regards, Kristof ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
sry forgot details: source tree @ ead01bfe8 git -C /usr/src checkout gf20c0e331 error: pathspec 'gf20c0e331' did not match any file(s) known to git what is the 'g' for? git -C /usr/src checkout f20c0e331 M sys/amd64/conf/GENERIC HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root bundle yet I don't see any indication that anything changed, and now it wont update at all: git -C /usr/src pull --ff-only You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull On 12/28/20 7:56 PM, Pete Wright wrote: On 12/28/20 4:38 PM, monochrome wrote: what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src I will generally just checkout the short git hash like so in my local checkout: $ git checkout gb81783dc98e6 you can quickly get the hashes by running "git log" from your checkout. cheers, -pete ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
this didn't seem to work, and now git is saying: You are not currently on a branch. since the incremental numbers aren't in the git log does it make more sense to use the short hash like this? other different responses were focused on the incremental commit number. Also, I saw someone mention that a 12 digit shortened hash is the standard to use, yet uname only spits out 9? thanks On 12/28/20 7:56 PM, Pete Wright wrote: On 12/28/20 4:38 PM, monochrome wrote: what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src I will generally just checkout the short git hash like so in my local checkout: $ git checkout gb81783dc98e6 you can quickly get the hashes by running "git log" from your checkout. cheers, -pete ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On Mon, Dec 28, 2020 at 04:56:39PM -0800, John-Mark Gurney wrote:
> monochrome wrote this message on Mon, Dec 28, 2020 at 19:38 -0500:
> > what would be the git command for reverting source to a previous version
> > using these numbers? for example, with svn and old numbers:
> > svnlite update -r367627 /usr/src
> >
> > this is needed often when it blows up for someone tracking current
>
> Get the hash from a commit number:
> $git rev-list --reverse HEAD | tail -n +255241 | head -n 1
> 3cc0c0d66a065554459bd2f9b4f80cc07426464a
>
> so:
> git checkout $(git rev-list --reverse HEAD | tail -n +255240 | head -n 1)
>
Or save a process:
git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}'
3cc0c0d66a065554459bd2f9b4f80cc07426464a
(And thus:
git checkout $(git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}')
Could also pass the number to awk via the "-v var=value" command-line.)
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
While Trump successfully conned a lot of people for a while, in the
end he's just a failure throwing a temper tantrum because he lost.
See https://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: git and the loss of revision numbers
monochrome wrote this message on Mon, Dec 28, 2020 at 19:38 -0500: > what would be the git command for reverting source to a previous version > using these numbers? for example, with svn and old numbers: > svnlite update -r367627 /usr/src > > this is needed often when it blows up for someone tracking current Get the hash from a commit number: $git rev-list --reverse HEAD | tail -n +255241 | head -n 1 3cc0c0d66a065554459bd2f9b4f80cc07426464a so: git checkout $(git rev-list --reverse HEAD | tail -n +255240 | head -n 1) > On 12/28/20 11:27 AM, Ed Maste wrote: > > On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: > >> > >> FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 > >> 3cc0c0d66a0-c255241(main)-dirty: > >> ^ > >> This is an incremental counter of commits > > > > Also, uqs@ recently fixed an issue in newvers.sh (including the final, > > non-updating svn revision) and reordered the information. An example > > of the new format: > > > > main-c255126-gb81783dc98e6-dirty > > \ \ \\ > >\ \ \ local modifications > > \ \hash > > \ commit count > >branch -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On 12/28/20 4:38 PM, monochrome wrote: what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src I will generally just checkout the short git hash like so in my local checkout: $ git checkout gb81783dc98e6 you can quickly get the hashes by running "git log" from your checkout. cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src this is needed often when it blows up for someone tracking current On 12/28/20 11:27 AM, Ed Maste wrote: On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 3cc0c0d66a0-c255241(main)-dirty: ^ This is an incremental counter of commits Also, uqs@ recently fixed an issue in newvers.sh (including the final, non-updating svn revision) and reordered the information. An example of the new format: main-c255126-gb81783dc98e6-dirty \ \ \\ \ \ \ local modifications \ \hash \ commit count branch ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: > > FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 > 3cc0c0d66a0-c255241(main)-dirty: > ^ > This is an incremental counter of commits Also, uqs@ recently fixed an issue in newvers.sh (including the final, non-updating svn revision) and reordered the information. An example of the new format: main-c255126-gb81783dc98e6-dirty \ \ \\ \ \ \ local modifications \ \hash \ commit count branch ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
On 24/12/20 11:15, Michael Grimm wrote: Correction: On 24. Dec 2020, at 15:11, Michael Grimm wrote: In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a larger revision number than those in advisories or notices. In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a smaller revision number than those in advisories or notices. FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 3cc0c0d66a0-c255241(main)-dirty: ^ This is an incremental counter of commits -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
Christian Weisgerber wrote: > > Michael Grimm: >> Correct? If so I wonder how future security advisories and errata notices >> will be composed. Will there be a date of the commit besides its hash being >> reported? > > For over TWENTY YEARS, FreeBSD advisories have already contained > the date when the problem was corrected, e.g.: Ups, sorry for my fading memory ;-) I must have concentrated solely to the revision numbers and descriptions in order to find out whether to recompile or not. > I think it is safe to assume that this practice will continue after > the switch to Git. Thanks to all who responded and helped me to understand what to expect. Pointing me to git-rev-list(1) has been very helpful. I came to the conclusion that I will name my BE by date and time of latest pull before buildworld or buildkernel, e.g. 2025_0955. That will help me to make decision as mentioned above. With kind regards, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
> Disclaimer: I just started to learn git, never used it before. > If I do understand it correctly, the switch from svn to git comes with a loss > of continuously increasing revision numbers. Correct? If so I wonder how > future security advisories and errata notices will be composed. Will there be > a date of the commit besides its hash being reported? > In the past I could easily judge if there was a need to buildworld or > buildkernel: If uname shows a larger revision number than those in advisories > or notices. > Question: How may one find out whether to recompile or not in the future? > Thanks and regards, > Michael It is good to have a revision number available through uname -a or otherwise. Not sure about how Haiku does that, but Haiku uses tags that are noticeable when downloading (git clone or pull). I believe tags show the revision number. I haven't run Haiku in several years; all I have is USB-stick image from November 2012, downloaded 2014 (?), too old to be able to compile newer versions, and trying to cross-compile from FreeBSD or NetBSD has never been successful. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
Michael Grimm: > If I do understand it correctly, the switch from svn to git comes with a loss > of continuously increasing revision numbers. Correct. > Correct? If so I wonder how future security advisories and errata notices > will be composed. Will there be a date of the commit besides its hash being > reported? For over TWENTY YEARS, FreeBSD advisories have already contained the date when the problem was corrected, e.g.: Topic: Several vulnerabilities in procfs [REVISED] Category: core Module: procfs Announced: 2000-12-18 Reissued: 2000-12-29 Affects:FreeBSD 4.x and 3.x prior to the correction date. Corrected: 2000-12-16 (FreeBSD 4.2-STABLE) 2000-12-18 (FreeBSD 3.5.1-STABLE) I think it is safe to assume that this practice will continue after the switch to Git. -- Christian "naddy" Weisgerber na...@mips.inka.de ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
> loss of continuously increasing revision numbers git rev-list --count HEAD git describe --tags / parent Plus a bunch of similar ways to do it, from different points, in different formats, search internet for them all... git revision version numbering... Some deploy structured metadata in tag schemes, use hooks, files, etc but gets messy and is not just a simple proper read-only query. > date of the commit besides its hash being reported > whether to recompile Recompilation means users have the source cloned. Source means users can use ways like git log git show etc Which means users have date, and a in log subsequent to their last compiled hash etc. So it's not a problem beyond a few trivial steps or shell parsing function to query and compare on whatever particular metadata a person may like, to what they already know they have. The handbook will have docs on some ways. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git and the loss of revision numbers
Correction: > On 24. Dec 2020, at 15:11, Michael Grimm wrote: > > In the past I could easily judge if there was a need to buildworld or > buildkernel: If uname shows a larger revision number than those in advisories > or notices. In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a smaller revision number than those in advisories or notices. Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
