Deprecating base system ftpd

[zirias@]

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?

 

[PMc]

I

Actually, they serve the same purpose. E.g. assuming you have a hash b7fbdb5042c in your uname output (a commit that actually exists on releng/13.0), you could inspect exactly what changed since then with git diff b7fbdb5042c.

Only if you manage to still find that hash. That means, if it still exists.
I noticed some interesting things with rebase and tags...

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!
That's already bad enough - 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).

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).

So, commit id hash is very useless for documentation. And this again is caused by the design weakness of git.
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.

edit: BTW, your uname -a output looks like mine. So, still wondering what PMc is doing here

I'm doing nothing, this is the standard reproducible build that you now get without asking.
Both of You seem to have that switched off - usually this is done by configuring WITHOUT_REPRODUCIBLE_BUILD to make.

 

[zirias@]

Oh, a long rant, how nice.

Fact one: You have the option to have local branches/commits now, you're not obliged to use them. If you use them, putting your own commit hashes in uname output is the only sane thing to do. With subversion, you just didn't have the option.

Fact two: Whether you rebase your original branch or a copy of it is your decision.

And this again is caused by the design weakness of git.

The typical arrogant nonsense from a person who doesn't understand the design.

 

[PMc]

So what? git-tiny is a tiny package. Complaint-mode?

Tiny package with some 89 build-prereqs, with most options turned off.

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

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).

 

[zirias@]

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),

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.

 

[PMc]

Once again, as thats for the engineering demand:

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).

So how do we get that into uname?

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.

That figures. If the rough winds of serious engineering demands don't suit, then just withdraw into some filter-bubble.

 

[zirias@]

Does it get any more moronic?

You're complaining about GIT, giving you NEW features, and then request something without showing any need for it that was never possible before because SVN didn't even offer the prerequisites to get there. All for miserably failing to understand how these things work with GIT.

Yes, I won't answer on your "content" any more.

 

[mickey]

It's extremely obvious, just have a look at the URL.

Use the source, Luke!

 

[zirias@]

Use the source, Luke!

Yep, that's what olli@ already mentioned. Leaves the question: What disables it, short of explicitly doing so? Is some added kernel config enough? That's strange, but wasn't the "issue" here (although, OTOH, there is no real "issue" here anyways…)

 

[olli@]

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?

When 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.

 

[zirias@]

Hm, 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 building GENERIC.

But anyways, doesn't really bother me

 

[olli@]

Hm, 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

Well, basically it runs svnversion and/or git diff-index in order to find out.
If you’re curious, you can read all the details in /sys/conf/newvers.sh (look for the variable modified).

 

[Jose]

Only if you manage to still find that hash. That means, if it still exists.

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.

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!

Well, if you rebase onto a remote-tracking branch, your local history will always have a common ancestor with the upstream branches.

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).

You shouldn't rely on these existing. They will be garbage collected eventually.

So, commit id hash is very useless for documentation. And this again is caused by the design weakness of git.

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.

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.

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.

I find that it follows the Unix philosophy in that it will not try to protect you from the consequences of your actions. It will cheerfully do very destructive things if you ask it to because the assumption baked into the tool is that you know what you're doing. Yes, I've burned my fingers with it, but it's still my kind of tool.