zirias@
Developer
Huh? Then why did I never see such a shortened uname? I didn't have any local patches on 12.2. Were additional kernel configs enough to disable it?Only in HEAD and 13. It is on by default in FreeBSD 12.
Huh? Then why did I never see such a shortened uname? I didn't have any local patches on 12.2. Were additional kernel configs enough to disable it?Only in HEAD and 13. It is on by default in FreeBSD 12.
Only if you manage to still find that hash. That means, if it still exists.Actually, they serve the same purpose. E.g. assuming you have a hashb7fbdb5042c
in your uname output (a commit that actually exists on releng/13.0), you could inspect exactly what changed since then withgit diff b7fbdb5042c
.
I'm doing nothing, this is the standard reproducible build that you now get without asking.edit: BTW, youruname -a
output looks like mine. So, still wondering what PMc is doing here
WITHOUT_REPRODUCIBLE_BUILD
to make.uname
output is the only sane thing to do. With subversion, you just didn't have the option.The typical arrogant nonsense from a person who doesn't understand the design.And this again is caused by the design weakness of git.
Tiny package with some 89 build-prereqs, with most options turned off.So what? git-tiny is a tiny package. Complaint-mode?
No idea what you have here or from which version that is (and that's exactly what I am talking about all the time: in git you just don't find the relevant matters), but in my 12.2 Release source it is always ON by default (and I didn't patch that).I don't know what you do to your source, but "reproducible build" is always off by default:
kern.opts.mk « conf « sys - src - FreeBSD source tree
cgit.freebsd.org
It's extremely obvious, just have a look at the URL. This is getting ridiculous, only nonsensical complaints. I guess I'm out of here, the mailing lists and IRC channels are a much better place nowadays.No idea what you have here or from which version that is (and that's exactly what I am talking about all the time: in git you just don't find the relevant matters),
we would like to also have included in uname the hash from the branch-off commit, i.e. the last official commit contained in this checkout (because that one should stay constant).
uname
?That figures. If the rough winds of serious engineering demands don't suit, then just withdraw into some filter-bubble.It's extremely obvious, just have a look at the URL. This is getting ridiculous, only nonsensical complaints. I guess I'm out of here, the mailing lists and IRC channels are a much better place nowadays.
WhenHuh? Then why did I never see such a shortened uname? I didn't have any local patches on 12.2. Were additional kernel configs enough to disable it?
REPRODUCIBLE_BUILD
is enabled (default on FreeBSD 12), it passes the option -R
to the newvers.sh
script during the kernel build. This option is documented thusly:# -R Reproducible build if the tree represents an unmodified
# checkout from a version control system. Metadata is
# included if the tree is modified.
Well, basically it runsHm, not sure this does "the right thing" then, seems to consider two added files to sys/amd64/conf not under version control a "modified tree", even when
svnversion
and/or git diff-index
in order to find out.modified
).The commit (and therefore its hash) will always exist if it's in the history of any branch or tag. Orphan commits will linger until Git does garbage collection.Only if you manage to still find that hash. That means, if it still exists.
Well, if you rebase onto a remote-tracking branch, your local history will always have a common ancestor with the upstream branches.So, problem one: that hash is the commit-id from the tip of the branch. This might be the commit of your local patches on top of the release - then this hash is not to be found anywhere else than in your local repo clone!
You shouldn't rely on these existing. They will be garbage collected eventually.But it comes worse: as soon as you do rebase your local patches on top of the official branch (due to some security fix or whatever), the commits are rewritten anew, and this commt id hash is gone! (It actually is not really gone, you can find it lingering somewhere in the repo, but it's no longer referenced).
We can agree to disagree on this, but commit hashes have a very interesting property: they are globally unique. They identify the state of the source tree at a particular point, and cannot be forged. If you like database analogies, this makes them a natural primary key for the source at a particular point. Revision numbers as used by CVS and Subversion are surrogate keys.So, commit id hash is very useless for documentation. And this again is caused by the design weakness of git.
I agree that Git is not for everyone. I personally like it and find using other RCS torture, but I can see how using Git can be a pain.We already agreed that git cannot provide us with monotonously increasing commit numbers, by design.
We already agreed that git cannot provide us with joint repositories where multiple similar projects could be maintained synchronously, by design.
Now we learn that git cannot easily provide us with solid tags for documentation purposes. The reason appears to be that git is not designed for such. It is NOT a database (a database would allow history-rewriting, but would do so only with strict cross-logging all previous and changed parameters). It is NOT EVEN a journal (a journal would strictly not allow to rewrite history).
Instead, it is just some kind of tree structure, similar to a filesystem, where you can do anything with, and always have only an ad-hoc layout. Git is not used as a VCS, it is abused as a VCS.