# HEADS UP: FreeBSD changing from Subversion to Git this weekend



## bsdimp (Dec 17, 2020)

Greetings,

The FreeBSD project will be moving it's source repo from subversion to git
starting this this weekend. The docs repo was moved 2 weeks ago. The ports
repo will move at the end of March, 2021 due to timing issues.

The short version is that we're switching the version control we're using.
This switch will preserve much of the current FreeBSD development workflow.
After the switch, the subversion repo will become almost read-only. All
future work will be done in git, however as a transition aide we'll be
replaying the MFCs to stable/11, stable/12 and the related releng branches
for the life of those branches.

For more detailed information, please see
https://github.com/bsdimp/freebsd-git-docs/ for the current documentation.

Please see https://wiki.freebsd.org/git for the latest detailed schedule
(please note that this schedule is subject to change).

Warner


----------



## a6h (Dec 17, 2020)

Regarding the non-Committer aka read-only checkout for normal users:
1. Should we delete our SVN-based directories e.g./usr/doc right now,
and checkout new repo from the GIT, or the SVN is still working for us?
2. Is there an estimated deadline for the end of the readonly SVN repo?


----------



## a6h (Dec 17, 2020)

Does FreeBSD GitHub repo replicate in other servers outside of the U.S., or rest of us are subject to Microsoft/U.S. possible restrictions laws/policies in the future?
For example, if for whatever reason, Microsoft/GitHub decides impose regional/IP-range restrictions on GitHub servers, that implies no FreeBSD source checkout!
I'm just speculating and don't imply anything, but these corporations have a history of imposing blanket ban (service/medium) on individuals/regions in the past.


----------



## msplsh (Dec 17, 2020)

My understanding is that github is not the master, just a mirror, so you'd be pulling from FreeBSD, not them.


----------



## rigoletto@ (Dec 17, 2020)

vigole said:


> Does FreeBSD GitHub repo replicate in other servers outside of the U.S., or rest of us are subject to Microsoft/U.S. possible restrictions laws/policies in the future?
> For example, if for whatever reason, Microsoft/GitHub decides impose regional/IP-range restrictions on GitHub servers, that implies no FreeBSD source checkout!
> I'm just speculating and don't imply anything, but these corporations have a history of imposing blanket ban (service/medium) on individuals/regions in the past.


The 'sources of the truth' are the FreeBSD own servers then mirrored to both GitHub and GitLab. Btw, GitLab download considerably faster than GitHub *for me*.


----------



## chessmaster (Dec 20, 2020)

So git clone would be the new way to get sources? Reason I ask is there was no mention. Of subversion becoming the "obsolete", way of checking out the default "/usr/src".


----------



## msplsh (Dec 20, 2020)

Probably not going to make any difference until after the handbook is updated.


----------



## PMc (Dec 20, 2020)

It certainly makes a difference: it does away with the very reason why I dumped linux and switched to FreeBSD in 1995 (order and discipline).


----------



## ralphbsz (Dec 20, 2020)

Can we perhaps discuss the technical aspects (how to switch) in this thread, and leave the activism and politics of it to a thread in off-topic?


----------



## shkhln (Dec 20, 2020)

Poor, poor SVN.


----------



## PMc (Dec 20, 2020)

ralphbsz said:


> Can we perhaps discuss the technical aspects (how to switch) in this thread, and leave the activism and politics of it to a thread in off-topic?


I didn't see any non-technical aspects mentioned here. And how to switch is simple: just throw away your entire deploy toolchain that was grown over the last 12 years (if it is based on monotonously increasing version numbers) and write a new one from scratch.


----------



## shkhln (Dec 20, 2020)

PMc said:


> just throw away your entire deploy toolchain


Let's not be overly dramatic.


----------



## PMc (Dec 20, 2020)

shkhln said:


> Let's not be overly dramatic.


I don't remember You ever mentioning that You would even utilize a deploy toolchain of Your own make...


----------



## shkhln (Dec 20, 2020)

Can you describe the technical side of your issue? What do you do with those increasing revision numbers?


----------



## PMc (Dec 20, 2020)

Well, on the large scale, I do most of what tools like e.g. poudriere offer (but by utilizing zfs snapshots), plus including rollouts of the base distribution (buildworld & friends) into the scheme.
On the small scale, these are monotonously increasing revision numbers.  Recently there was a switch from CVS to SVN (and that switch had a _technical_ justification), and the monotonously increasing revision numbers were one of the gifts provided by that switch (at that time things were still changing for the better). CVS, if You mind to recall, would have had monotonously increasing revision numbers also, but these would change independently and separately for each and every file, which is quite unmanageable without utilizing tags. SVN, on the contrary, does not need tags, because the revision number is enough to uniquely specify the entire distribution, and is also suitable to compare which one is newer. (Tags cannot be compared numerically.)


----------



## rigoletto@ (Dec 20, 2020)

Could someone explain me why sometimes I run 'git pull' on some repository absolutely *no* local change (e.g. src happened today) and I receive a total mess of conflicts, and git ask to commit my local changes (or something like that)?


----------



## ralphbsz (Dec 21, 2020)

rigoletto@ said:


> Could someone explain me why sometimes I run 'git pull' on some repository absolutely *no* local change (e.g. src happened today) and I receive a total mess of conflicts, and git ask to commit my local changes (or something like that)?


Never seen something like that.

To PMc's questions: Your complaint about CVS having independent version numbers for each file is closely tied to the fact that CVS doesn't have "change sets". That means: one commit can change several files at once, and the whole commit is either applied or undone or merged between branches as a unit. I think that's a vitally important functionality, and I think all modern version control systems have it.

The big problem with version numbers not being monotonic is due to the distributed nature of git, and is pretty much unavoidable in a distributed source control system. Say the current release of some artifact is 42. Alice checks it out, modifies it, and commits it to some git archive somewhere. Now it is version 43. Bob also gets a copy of the version 42, and also changes it. Can he make it version 43? No, then we would have ambiguity. Can he find out that Alice has already created version 43 and go to 44? No, because in a distributed system, there is no way for him to know that Alice exists, or contact her repository. Matter-of-fact, the impossibility of assigning increasing version numbers is an example of the FLP and CAP theorems of distributed computing: to get consensus on version numbers, one would either need a central server (like what CVS and Subversion use), or each participant in the protocol needs to know who all the other participants are (and then one can use something like a Lamport clock or Paxos or Chandra-Toueg). But that would restrict git too much, for its intended usage pattern (of completely independent developers). I don't think it's even possible in general to determine whether two versions of a file are "earlier" or "later": Say one file has two copies, one of which has changes 1, 2 and 4, and the second has changes 1, 3 and 4: which one should have the higher version number? That question just doesn't make sense. With independent changes, files are not like numbers, where it is true that a<b, a=c or a>b is always true. The question one can ask: does one version of a file contain all the changes of another version? With that, one can get a partial ordering, I think, but definitely not a complete ordering.

So in a nutshell: Any workflow that relies on increasing version numbers is toast. We could see that one coming a mile away. By the way, I've gone through the same pain. I used to have CVS version numbers in all my source files, and the main program would typically know how to collect them all and print them, so you could see what all the parts were. What I instead do today is to use the time last changed as the "best guess" at a version number, and then also print the git/mercurial revision string (which is a random-looking but unique 48 or 64-bit hex number). With ntp pretty reliable today, and my source code not changing very quickly, the "time last changed" is a pretty reliable indicator.


----------



## PMc (Dec 21, 2020)

ralphbsz said:


> The big problem with version numbers not being monotonic is due to the distributed nature of git, and is pretty much unavoidable in a distributed source control system. Say the current release of some artifact is 42. Alice checks it out, modifies it, and commits it to some git archive somewhere. Now it is version 43. Bob also gets a copy of the version 42, and also changes it. Can he make it version 43? No, then we would have ambiguity. Can he find out that Alice has already created version 43 and go to 44? No, because in a distributed system, there is no way for him to know that Alice exists, or contact her repository.



Well, they might just talk to each other. At least, in my youth that was a very common thing to do - specifically if one would work together on something.

So, lets subsume:  The purpose of distributed revision control is that people can work simultaneously on the same piece of code, while being properly cage-kept and maintaining communications ban, and/or not even knowing that the other worker would exists.
That is indeed an interesting concept of "cooperation".



ralphbsz said:


> Matter-of-fact, the impossibility of assigning increasing version numbers is an example of the FLP and CAP theorems of distributed computing: to get consensus on version numbers, one would either need a central server (like what CVS and Subversion use), or each participant in the protocol needs to know who all the other participants are (and then one can use something like a Lamport clock or Paxos or Chandra-Toueg). But that would restrict git too much, for its intended usage pattern (of completely independent developers). I don't think it's even possible in general to determine whether two versions of a file are "earlier" or "later": Say one file has two copies, one of which has changes 1, 2 and 4, and the second has changes 1, 3 and 4: which one should have the higher version number? That question just doesn't make sense.



That is not the question I would ask. The question I would like to as is rather:
When we ever can come to such a point, who then was in charge and has verified that changes 2 and 3 work properly together?


----------



## shkhln (Dec 21, 2020)

PMc said:


> SVN, on the contrary, does not need tags, because the revision number is enough to uniquely specify the entire distribution, and is also suitable to compare which one is newer. (Tags cannot be compared numerically.)


For deployment? Why do you want to compare them anyway? What if there is a regression in any particular revision?



rigoletto@ said:


> Could someone explain me why sometimes I run 'git pull' on some repository absolutely *no* local change (e.g. src happened today) and I receive a total mess of conflicts, and git ask to commit my local changes (or something like that)?


That means somebody used `git push`, thus partially rewriting remote history. Git sees different hashes (diverging histories) and refuses to pull those changes automatically. You should probably `git reset --hard` a few local commits and try `git pull` again.


----------



## Lamia (Dec 21, 2020)

How soon can we expect this page - https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html - to be updated? Svn checkout does not yield ports update. And we should be reading git {clone, pull, etc} from it by now? 

Is the anyone there that their poudrière fetches updates? 

No updates from here - svn://96.47.72.69/ports/branches/2020Q4.


----------



## ralphbsz (Dec 21, 2020)

PMc said:


> Well, they might just talk to each other. At least, in my youth that was a very common thing to do - specifically if one would work together on something.
> 
> So, lets subsume:  The purpose of distributed revision control is that people can work simultaneously on the same piece of code, while being properly cage-kept and maintaining communications ban, and/or not even knowing that the other worker would exists.


Actually, fully distributed source control means that people can make progress exactly WITHOUT talking to each other. And that's because in some open source development models, there is no central authority, no administration. For example, say there is a piece of code that knows how to count walking elephants. One programmer might enhance it for their own purposes, to also count flying elephants. Another programmer might start from the original base, and also count walking rhinos. Both can publish their changes. A third programmer might then pull both changes in, and create code that can count all pachyderms, walking or flying, without having to coordinate with any of them. None of them need to cooperate. It does create a lot of freedom, without any paranoia.



> When we ever can come to such a point, who then was in charge and has verified that changes 2 and 3 work properly together?


Why does anyone has to be in charge? And from a software quality point of view: I would expect that anyone who writes any change follows good software engineering practices, writes a clear requirements document, reviews all artifacts, and test their code after it is done. The fact that you can mix-and-match changes from many sources doesn't have to reduce quality, if the developers have a mindset of creating high quality software.


----------



## Lamia (Dec 21, 2020)

Lamia said:


> How soon can we expect this page - https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html - to be updated? Svn checkout does not yield ports update. And we should be reading git {clone, pull, etc} from it by now?
> 
> Is the anyone there that their poudrière fetches updates?
> 
> No updates from here - svn://96.47.72.69/ports/branches/2020Q4.


Here is the information - http://bsdimp.blogspot.com/2020/10/freebsd-git-primer-for-users.html?m=1 - should anyone be interested.


----------



## msplsh (Dec 21, 2020)

Ports isn't ready, date is March.


----------



## PMc (Dec 21, 2020)

ralphbsz said:


> Actually, fully distributed source control means that people can make progress exactly WITHOUT talking to each other. And that's because in some open source development models, there is no central authority, no administration. For example, say there is a piece of code that knows how to count walking elephants. One programmer might enhance it for their own purposes, to also count flying elephants. Another programmer might start from the original base, and also count walking rhinos. Both can publish their changes. A third programmer might then pull both changes in, and create code that can count all pachyderms, walking or flying, without having to coordinate with any of them. None of them need to cooperate. It does create a lot of freedom, without any paranoia.


Yes, thats a nice idea about freedom. But there is a misconception: writing an OS is not a means in itself, done by the pure ambition of self-fulfillment no matter the outcome; it is instead a means to an end: to create something that actually works.

Now I perfectly understand that our ivory-tower league, namely the developers, are mainly interested in their self-fulfillment - and that's perfectly alright. But then, issues of freedom and paranoia have no place in engineering, and should actually rather be discussed with a therapist.

Anyway, we did already have exactly that, with Linux, in 1995 (and from what I learned, it has not changed in the meantime):
[the following is all practical, real and authentic experience of my own - it is in no way made up]

Act 1.
It begins with the code not doing the expected thing. You read the source and you figure, it should do the expected thing! Finally you figure out: the source is not from what the object was built! Somewhere there was a change - nobody knows where, nobody knows what, nobody knows why - and version numbers are a chaotic heap, so you never know what you're actually running.

Act 2.
Then, if you finally go and find some source to compile it yourself, to at least get an object that matches your source - there is no means to figure out if this source is the appropriate one matching to the rest of the system. Because it is a bazaar: there are lots of sources you can choose from. There are lots of versions of these. And, specifically, there is no monotonous numbering, so you cannot just read the commitlog in sequence, to understand what has developed and how we have gotten here.

Act 3.
During that process of looking into the source, you practically always find a bunch of bugs, mistakes and coding errors on the wayside. Some are obvious mistakes, and could just be corrected. But most are related to and interdependent with other functionality - so to solve the matter, one would first need to talk to the auther, to evaluate what they actually thought when writing it that way.
But, as You explained, we do not do this. We don't talk to each other anymore.

Act 4.
Finally, you may find a commit log that actually identifies the auther of something. But that doesn't help you in any way. Because all you get is a cipher under which the author writes. The actual contact data is protected, and is only uncloaked to customers of the github corporation.
But even then, if you manage to find some customer of github, and manage to have some message dispatched to the author, you may most likely not get a reaction.
Because, as You explained, we do not do this. We don't talk to each other anymore.


Exactly this is the reason why I dumped linux. And when I was pointed to FreeBSD, it became immediately obvious that here the things were done in the right way. There was a consistent codebase. The code in /usr/src would always exactly represent the running object, because it was built from there: straight down the line.
And, most important: there were people! People who knew what they were doing - people with a skill level so that I still think I should rather call them demi-gods.[1] And these people were going fully open! They were visible in public discussions, and they had signatures like old-school Usenet, like scientists have: sometimes even with full address and phone!

Now, today, all this has already decayed. Gradually and slowly, but nevertheless. In the old time, if you were to send a bug report, it got processed. Sometimes quickly, sometimes one or two years later. But it got processed.
Now we have tool to store away the bugreports, so that nobody needs to bother reading them.
And obviousely, as You have explained, everybody is just throwing in their beloved features, without ever caring for anything else, and none of these nor anybody else feels responsible for the outcome. So who should be concerned about bugs, at all? Obviousely nobody.

Then, as Zirias described in his paper (paragraph 7.), FreeBSD once had a culture of fixing and improving things over time. But no longer.

Nowadays, things are just thrown over the fence, I mean, into the codebase - and then the author disappears again. Take, for instance, the ULE scheduler. Since the beginning, people were complaining that it does not work well under all conditions. And consequentially there was great engagement in bullying those complainers, and telling them they should just revert to the old scheduler and shut up. (There was no engagement in looking into the code and figuring out what actually goes wrong there.)
Then, I was hit by the malfunction. So I grabbed dtrace, and figured what is going wrong (plus at least one additional bug found on the wayside). Obviousely, nobody cares. I have patches for these - I do not know if they make the behaviour better over-all; they just fix the malfunction I was running into. Obviousely, nobody cares.

I finally managed to figure the e-mail of the original author, and he actually responded! But then, he seems to be adherent to the google code-of-conduct (bottomline: "we just want to be happy developers, and we do not want to talk about nasty and unpleasant things, specifically not about such abominable things as bugs and malfuctions"). So, as soon as the topic came to bugs, communication stalled.


[1] Strange story on the wayside: when later I got a job, and started to do consulting, i.e. building Unix client/server infrastructures and Internet functionality for major european banks and insurance companies, I was considered a "guru" by my fellow consultants - because I was almost the only one there who would ever have looked into the source, who might even dare to write a kernel driver if need arises. While the others were mostly focused on reading release notes and doing installations/configurations along the book.
OTOH there were these demi-gods of the Berkeley OS: people like e.g. HPSelasky, or Matt Dillon - there was a couple of dozens of those, and their skill was so many magnitudes above what I could imagine, I never even dared to talk to them.



ralphbsz said:


> Why does anyone has to be in charge? And from a software quality point of view: I would expect that anyone who writes any change follows good software engineering practices, writes a clear requirements document, reviews all artifacts, and test their code after it is done.



Yes, I was already waiting for that test-crap coming up. This is indeed what seems to be the new mindset: lets write any crap we want, because we have tests in place, and the tests will tell us if the crap works or not, and lets finally do away with any attempt for logical verification (commonly termed: "thinking").
Proper engineering means to logically think through the stuff, to understand what it does, in relation to the other components and the system as a whole. And this certainly cannot be done when you don't even know the other components.
I know that this is the point where it hurts - because people get very violent when you try to make them think - thinking is painful to them, and they want to avoid it.



ralphbsz said:


> The fact that you can mix-and-match changes from many sources doesn't have to reduce quality, if the developers have a mindset of creating high quality software.


It is all about the mindset - and the mindset is that we have tests in place as a rope to catch us when we fall. And you behave entirely different when you know that you are protected: you no longer strive to behave error-free; you create more crap, because you think nothing too bad can happen from it. High quality is already abandoned at that point.

But also, the problem is: tests don't catch you when you fall! Tests can only protect from re-introducing problem that are already known (and fixed). Because, a test needs to be written first, and it can only be written if somebody has thought about and knows that there can be a possible malfunction that should be tested against.

I know the agile culture came up with a pragma that there should be at least as many LOC of tests as of active code, and so they started to create their test code automatically. Very great - so there is zero skill going into the tests, and you could just leave them away and have the same.


But, over all, I think we must understand that the ambitions of the users and those of the developers *point in exactly the opposite direction*.
While the users choose FreeBSD for reasons like those I mentioned above, or those Zirias  mentions in his paper, and many of them choose FreeBSD deliberately while *running away from Linux* (for reasons like those mentioned above), and therefore have no interest whatsoever in getting back the Linux workflow - to the contrary, the main interest of the developers is to put FreeBSD where it belongs, as *just another Linux distribution* - for very obviouse reasons: the more FreeBSD becomes Linux, the easier becomes porting.


----------



## zirias@ (Dec 21, 2020)

I think you might be interpreting a bit too much in a tool, sorry to say that 

In fact, GIT doesn't enforce a workflow, it's used in enterprises quite successfully (also where I work, we moved there from TFS which is much more comparable to SVN than GIT).

I think the move to GIT has just practical reasons. It's very fast, especially working with local branches is awesome, and getting reviews based on pull requests is also a pretty nice thing (don't know whether FreeBSD wants to use this).

I'm just in process of submitting an update to a port I maintain. I will open a PR with an attached diff. That's, well, okayish. For a simple change, it's all you need. I once had a bigger change where I prepared a git pull request, not for ever merging it, just as a nice review tool.

Well, in a nutshell, I'd argue the way the project works doesn't depend on the tool used. And IMHO, GIT is just the better tool nowadays.


----------



## PMc (Dec 21, 2020)

Zirias said:


> I think you might be interpreting a bit too much in a tool, sorry to say that


No problem with that - but I do not interpret this from the tool. I rather see the tool as one typical symptom (of many) for a longer-scale development that goes away from the traditional Berkeley culture and more and more to the Linux culture.

Maybe this is also a generational problem: I still know how to build a logic gate from two transistors - and then from there all the way up to the computers of today. And in the same fashion I want to connect all the things back to their root, recognizing the development in a hierarchical structure of building blocks put upon another.
People of today just cannot do that anymore, because it all became overwhelmingly broad. So it is more interesting to just select the piece that you want to work on.



> it's used in enterprises quite successfully



Yes, I understand that. It is probably the same reason why I got fired for my 20th job anniversary. Statement was, skill is no longer welcome at the company, as skill can now be easily obtained from the cloud. So if they need more skill, they can just buy more cloud.



Zirias said:


> . And IMHO, GIT is just the better tool nowadays.


Question is, what is actually better there? What are the gifts one would get in a practical means?

Because, by practical means, my experience is just that nothing works.
Imagine some arbitrary port from the ports system, where the source is maintained at github. Now imagine I have a problem with that port and want to look into the revision history to understand why it was written that way. On github there is a chooser for "branches" and "tags". All of these have arbitrary names, and none of them has any resemblance to the distributed versions that are downloaded by the ports system. So it is just not possible to read the revision history for the code that is actually distributed - like if there were no revision system at all.


----------



## zirias@ (Dec 21, 2020)

PMc said:


> Maybe this is also a generational problem: I still know how to build a logic gate from two transistors - and then from there all the way up to the computers of today.


Just for completeness: I know that as well (at least in theory, hehe) and I agree this is a very GOOD thing to know.


PMc said:


> Question is, what is actually better there? What are the gifts one would get in a practical means?


Ask 10 developers and get at least 4 different answers. But it DOES have more (and useful) features. I personally like how quickly it operates on your local "clone" and how you can work with local branches efficiently.


PMc said:


> On github there is a chooser for "branches" and "tags". All of these have arbitrary names, and none of them has any resemblance to the distributed versions that are downloaded by the ports system.


Or you can just look at, well, the history 

I personally don't like projects with thousands of published branches. At my company, we have a "single branch" policy, and I like it very much. Other branches are only published for creating and reviewing pull requests, and HAVE to be deleted afterwards. There's no need to publish your local, possibly long-running, branch, unless you need to work together with someone else on it.

All I say here: GIT is very flexible, you define your workflow and policies, and you just use GIT as a tool accordingly. We will see what FreeBSD makes of it. I personally have a good feeling here


----------



## ralphbsz (Dec 21, 2020)

(Talking about the Linux kernel)


PMc said:


> Somewhere there was a change - nobody knows where, nobody knows what, nobody knows why - and version numbers are a chaotic heap, so you never know what you're actually running.


At least up to Linux kernel 2.4 including, version numbers were exceedingly clear and numerically increasing, and could be found in the name of tar files at kernel.org. That goes up to about 2005 or so. After that, I stopped compiling my own Linux kernels.

(about distributed version control enabling distributed development)


> But, as You explained, we do not do this. We don't talk to each other anymore.


What I said is: We can now do development and re-merge development without central coordination. That doesn't mean that we have to stop using central coordination; git works perfectly well in a centralized model (with a single master repository) also. It also doesn't mean that one developer can't talk to another developer. It only means that they don't have to do these things.



> Finally, you may find a commit log that actually identifies the auther of something. But that doesn't help you in any way. Because all you get is a cipher under which the author writes. The actual contact data is protected, and is only uncloaked to customers of the github corporation.
> But even then, if you manage to find some customer of github, and manage to have some message dispatched to the author, you may most likely not get a reaction.


Do not confuse github (a commercial corporation, now owned by Microsoft) with git (a free/open piece of software). I have used git quite a bit (professionally for about 10 years, personally for about 5), and never created a github account, and never worked on any source that came from github. Every piece of code I've used in git has the clear-text e-mail address of the committer for each commit. To my knowledge, the FreeBSD source will not be controlled by the github copy (which is a secondary copy, not the master), so this issue doesn't arise.

Now the question whether developers respond to e-mails: That's up to them. In volunteer-run free/open software development, there is no way to force them. With commercial software, a customer has means (contract law) to force software vendors to fix bugs, and vendors have means to force developers to do so (as developers are employees, the paycheck is a pretty good carrot and stick). But the question of what version control system is being used doesn't change the relationship between user, bug and developer.

(About software quality)


> It is all about the mindset - and the mindset is that we have tests in place as a rope to catch us when we fall. And you behave entirely different when you know that you are protected: you no longer strive to behave error-free; you create more crap, because you think nothing too bad can happen from it. High quality is already abandoned at that point.


Please read what I said. The thing that determines code quality is the mindset of the developer. That encompasses many things. For example having clear requirements (knowing what the code is supposed to accomplish). For example creating well-crafted and easily understandable and maintainable artifacts. And to run tests to validate that these goals are being met. Tests are part of whole picture. You can't "test quality into software", but without any tests, you don't even know whether you have met your quality goals.

And to be clear: When I say tests, I don't only mean automated tests (which are part of the source code). I think just as important is a dedicated team of testers, in a corporate setting disconnected from engineering (they report to a different VP, so there is no temptation to fake test results), good test plans, room in the schedule and budget for testing. You talk about counting the LOC of tests; I don't like that metric at all. In my mind the correct metric is: for every software engineer on the payroll, you should have about 2 testers on the payroll.



> But also, the problem is: tests don't catch you when you fall! Tests can only protect from re-introducing problem that are already known (and fixed). Because, a test needs to be written first, and it can only be written if somebody has thought about and knows that there can be a possible malfunction that should be tested against.


Nonsense. If you write tests this way, your software process is broken. Tests are there to validate that requirements are being met. Example requirement: "This piece of software shall count the number of elephants in the zoo, and print a non-negative integer when run from the command line as ./count_elephant. If the computer is not installed in a zoo, it shall crash with a clear English error message. If the number of elephants is below 10, the count shall match exactly. If it is between 10 and 99, it shall match within 10%, and at 100 and above within 5%." How do you test this? Your test team sets up a fake zoo, catches a few elephants, and tries various scenarios (like 0, 9, 11 and 42 elephants), runs the program 100 times each, and performs statistics on the results. They could run regression ... making sure the accuracy doesn't get worse with new versions, and checks that the running time of the program is within reason. The could run the program at an aquarium, and check the spelink of the error message. This is testing. It has to be driven by requirements, not by last week's bug.

Old joke: A software company builds a bar. On the day before beta release, the tester walks into the bar, orders one beer, gets it and drinks it, all good. He orders zero beers, he orders 5 beers for his colleagues, he order sqrt(-1) beers, he orders qwertyuiop beers, he orders 6.02e23 beers, and in all cases he gets expected results. Signs off on public release. The next day, the first real customer comes in, asks what time it is, the bar explodes killing everyone in sight. Oops.

But: None of this discussion has anything to do with SVN versus git.


----------



## msplsh (Dec 21, 2020)

PMc said:


> On github there is a chooser for "branches" and "tags". All of these have arbitrary names, and none of them has any resemblance to the distributed versions that are downloaded by the ports system. So it is just not possible to read the revision history for the code that is actually distributed - like if there were no revision system at all.


This is the maintainer's fault.  People can use SVN like this (I do, for internal stuff).


----------



## Jose (Dec 21, 2020)

rigoletto@ said:


> Could someone explain me why sometimes I run 'git pull' on some repository absolutely *no* local change (e.g. src happened today) and I receive a total mess of conflicts, and git ask to commit my local changes (or something like that)?


By default, git-pull(1) does a fetch followed by a merge. This is probably not what you want, and yes `--rebase` should probably be the default. You may also find the `--ff-only` option interesting.

FWIW, newer versions of Git now warn you about pull modes. Personally, I set

```
[pull]
        rebase = true
```
in my ~/.gitconfig.

Rewriting history in a shared remote branch is bad form, and will get you yelled at in most places I've worked.



Zirias said:


> There's no need to publish your local, possibly long-running, branch, unless you need to work together with someone else on it.


I do this to back up local changes if my desktop is not getting backed up, or if I don't trust the backup.

BTW, the Github workflow with forks and multiple remotes is unnecessarily complicated for most people, and not needed to use Git for revision control.



PMc said:


> SVN, on the contrary, does not need tags, because the revision number is enough to uniquely specify the entire distribution, and is also suitable to compare which one is newer. (Tags cannot be compared numerically.


Git commit objects contain the entire state of the tree at a particular point as well.

I'm not saying that these features will allow to you adapt your workflow to Git, or that even if they do that it will be easy and quick, but you might find git-log and git-bisect(1) interesting.


----------



## Jose (Dec 21, 2020)

While I'm on my Git soapbox, let me advise you to never, ever use git-revert(1). It does not do what you would expect it to do.* A former colleague described what git-revert does in this memorable way: It creates an evil antimatter commit that will hunt down and destroy the changes you tried to revert, even if they are re-introduced much, much later. This can lead to some serious head-scratching when freshly-committed code disappears mysteriously.

* To me the most serious and trenchant criticism of Git is that many commands don't do what you would expect them to do based on your experience with other revision control systems. Git-revert is probably the most dangerous one, but git-checkout is likely the most annoying one. It does about 5 completely different things, none of which maps to what most of us think when we talk about "checking out the source tree".


----------



## zirias@ (Dec 21, 2020)

Never even heard of git revert although I use GIT for years. Maybe for the better 

Talking about do's and dont's with GIT, IMHO the most important one is: Never ever rewrite history on a public branch! Of course, GIT can be configured to reject any attempts to do so


----------



## PMc (Dec 21, 2020)

ralphbsz said:


> (Talking about the Linux kernel)
> 
> At least up to Linux kernel 2.4 including, version numbers were exceedingly clear and numerically increasing, and could be found in the name of tar files at kernel.org. That goes up to about 2005 or so. After that, I stopped compiling my own Linux kernels.


The event I was talking about happened in 1996. It concerned the return codes of the ping command. With ping, there is a deliberate difference between returncode 1 and 2. And people were relying on that for monitoring DSL lines.  
Now the fun part was: that Linux was delivered in source and binary. And the 1 and 2 returncodes for ping were exactly swapped between source and binary. I doubt that any of the "exceedingly clear and numerically increasing" version numbers would allow one to detect this (and instead of calling it 'bazaar', I prefer to call it 'saustall', anyway).

So yes, if a central coordination only ascertains so much as that source and binary do not run away from each other, it is already valuable.



ralphbsz said:


> Do not confuse github (a commercial corporation, now owned by Microsoft) with git (a free/open piece of software). I have used git quite a bit (professionally for about 10 years, personally for about 5), and never created a github account, and never worked on any source that came from github.


Well, to my knowledge, projects managed in git are hosted on github. (Or why else would there have been such a big hassle about these master keybase keys of web applications being automatically stored within the repo on github - ready for deploy, and ready for everybody to read?  )
Maybe this is not mandatory to do, but it seems to be what is expected and what everybody does.
In all these software projects, it is also expected for everybody who wants to report bugs or send in patches, to "simply sign up" to github first. But then, when you look at the fine print of that, it is actually a customer contract, including payment and pricing.
Thats why I call this the ivory-tower league.



ralphbsz said:


> Nonsense. If you write tests this way, your software process is broken. Tests are there to validate that requirements are being met. Example requirement: "This piece of software shall count the number of elephants in the zoo, and print a non-negative integer when run from the command line as ./count_elephant. If the computer is not installed in a zoo, it shall crash with a clear English error message. If the number of elephants is below 10, the count shall match exactly. If it is between 10 and 99, it shall match within 10%, and at 100 and above within 5%." How do you test this? Your test team sets up a fake zoo, catches a few elephants, and tries various scenarios (like 0, 9, 11 and 42 elephants), runs the program 100 times each, and performs statistics on the results


Such may happen in contractual software development. But I'm quite certain, it doesn't happen in free software. Simply because nobody pays for it. What happens is that the developers have some automated test suite to run, after they implement a change. And that's it. These 200% testers then are the user-base. Which is also fine.
What certainly does happen is writings test to not re-introduce bugs that have already been fixed - and that is a good thing, and much better than not doing it.


----------



## PMc (Dec 21, 2020)

msplsh said:


> This is the maintainer's fault.  People can use SVN like this (I do, for internal stuff).


You think it is a _fault_? Well, thank you, that's actually good news. (On my own, I just don't know if something would be considered a fault, or just culture...)


----------



## jb_fvwm2 (Dec 22, 2020)

Does anyone know the command to git up a subtree, like /usr/src/sys/i386/conf so beginners could practice and while the destination is elsewhere?
...
That's easy in svn...


----------



## a6h (Dec 22, 2020)

PMc said:


> to my knowledge, projects managed in git are hosted on github. [...] Maybe this is not mandatory to do, but it seems to be what is expected and what everybody does.


It depends on the project. For example OpenBSD has a read-only public git of its CVS repo on the GitHub for general public. But it still uses CVS for diffs, and I bet it will remain the same.


----------



## ralphbsz (Dec 22, 2020)

PMc said:


> Well, to my knowledge, projects managed in git are hosted on github.


Not at all necessary. You can use git and never get anywhere near github. I worked on a very large project (millions of lines, hundreds of person-years) that used git (we transitioned from CVS, and then later transitioned to an in-house custom tool), not open source, the source was heavily restricted (inside the company only, and not visible to all employees), and the development used a centralized model (with one central server as the source of truth). I've also used it on medium-size projects within a work group, again without github being involved at all.

Git is a free and open tool for source control. Anyone can use it. Github is one of the users, there are many others.


----------



## zirias@ (Dec 22, 2020)

jb_fvwm2 said:


> Does anyone know the command to git up a subtree, like /usr/src/sys/i386/conf so beginners could practice and while the destination is elsewhere?
> ...
> That's easy in svn...


That's technically impossible because there is never a standalone "working copy" with GIT but a clone of the whole repository, including all history etc.
This enables working quickly locally, even have your local branches nobody else will see, working offline, shaping a set of commits before pushing them to the "main" repository, and so on.


PMc said:


> So yes, if a central coordination only ascertains so much as that source and binary do not run away from each other, it is already valuable.


That's an organizational problem not solved by ANY VCS. A good way to make sure such things don't happen are for example CI builds from your central repository.


PMc said:


> [github] when you look at the fine print of that, it is actually a customer contract, including payment and pricing.


I don't know other countries, but at least in Germany, it wouldn't even be possible to sign a contract requiring payment that way. So I see no reason NOT to use github. It *does* have a nice web UI, of course including an issue tracker as well. You need a bit more tooling than just a VCS repository for a software project, so if you're not a large project like FreeBSD (or even Linux) operating your own infrastructure and tools, github has a nice and free offer (and others do as well, like e.g. bitbucket or gitlab – github is just the most widespread).

So, what if github would suddenly decide to only offer payed services? They probably wouldn't as their user base would drop immediately. But IF they would, well, you just move somewhere else? With GIT, you have copies of your whole repository. There's nothing simpler than moving your "central" GIT repository somewhere else.

Of course, if your project is NOT opensource, using github for it would require payment, and probably most companies use their own infrastructure instead. I personally use github for anything opensource, my own server (where I want to try adding www/gitea to have a nice web UI with additional tools as well) for closedsource stuff, and at work, we currently have a MS Azure DevOps server hosting the central GIT repos.


----------



## Lamia (Dec 22, 2020)

I have been using 2020Q4 branch of the ports with Poudrière for quite sometime. Before now, it was 2020Q3.

And now that we are on git, I would not want to be repeatedly changing the branch. 

My understanding is that the main/master branch is for the FreeBSD 13-current while the quarterly is for other versions. 

I would want to use only one branch at all times. Kindly advise me on how to go about it.


----------



## zirias@ (Dec 22, 2020)

Lamia said:


> My understanding is that the main/master branch is for the FreeBSD 13-current while the quarterly is for other versions.


The main branch of ports is for any supported release, plus CURRENT and STABLE.


----------



## Lamia (Dec 22, 2020)

Zirias said:


> The main branch of ports is for any supported release, plus CURRENT and STABLE.


Thanks Zirias. I could build most ports on a quarterly but not the master few months ago.


----------



## zirias@ (Dec 22, 2020)

Well, this shouldn't happen…
It's your choice whether you want to use quarterly snapshots, no matter which FreeBSD version you run


----------



## PMc (Dec 22, 2020)

Zirias said:


> I don't know other countries, but at least in Germany, it wouldn't even be possible to sign a contract requiring payment that way.


It certainly is possible in Germany, because I do it all the time. (For things I want to buy, things that offer value.)



Zirias said:


> So I see no reason NOT to use github. It *does* have a nice web UI, of course including an issue tracker as well. You need a bit more tooling than just a VCS repository for a software project, so if you're not a large project like FreeBSD (or even Linux) operating your own infrastructure and tools, github has a nice and free offer (and others do as well, like e.g. bitbucket or gitlab – github is just the most widespread).


Yes, it is exactly the same as with facebook. It provides nothing that you couldn't do with some effort on your own, preserving your independence; but everybody decides to use it, and then everybody complains that they are so powerful.
(But when I say, people are not thinking one centimeter before their nosetip, then I am considered evil. :/ )



Zirias said:


> So, what if github would suddenly decide to only offer payed services?


Then it would immediately become obvious that nobody actually needs them.
So, that is not the point - the point is simply that they have the right and the ability to do so. I for my part am wondering, all the time, why somebody would advertize git as a "_distributed service_", while at the same time collecting practically all software projects of the open souce onto one _centralized server_ - and that one then run by a private company with only a single ambition: money-greediness.
(That again seems to count into the column with the centimeter and the nosetip, aka the golden rule: _never reflect upon what you are doing_.)



Zirias said:


> They probably wouldn't as their user base would drop immediately.


Sure, they wouldn't. But what they easily might do, in cooperation with the government, is to exclude single projects that have an unwelcome agenda (where the definition of "unwelcome" might change with current political moods).



Zirias said:


> But IF they would, well, you just move somewhere else? With GIT, you have copies of your whole repository. There's nothing simpler than moving your "central" GIT repository somewhere else.


I doubt that. Even with facebook, people seem unable to "move somewhere else". 
This whole game is now about market domination, about "_there can be only one_".


----------



## zirias@ (Dec 22, 2020)

PMc said:


> It certainly is possible in Germany, because I do it all the time. (For things I want to buy, things that offer value.)


Definitely no. For a contract requiring payment online to be effective, it's not enough to have some "fine print". This would never hold before court, so it's moot.

And then, comparing github with facebook and (again) insisting everyone using GIT would use github suggests you don't have much experience with GIT and how it works yet…

There's no way to move data away from facebook. GIT is opensource, standardized, and every clone is a full repository, you just push it somewhere else with 2 simple commands and you're done.


----------



## shkhln (Dec 22, 2020)

Zirias said:


> insisting everyone using GIT would use github


It's like suggesting that everybody using CVS should move to SourceForge. Even if FreeBSD wanted to move to GitHub, their issue tracker is incapable of managing a 250000+ bug database. Self-hosted GitLab instance is probably not an option for storing that many issues as well.


----------



## PMc (Dec 22, 2020)

Zirias said:


> Definitely no. For a contract requiring payment online to be effective, it's not enough to have some "fine print". This would never hold before court, so it's moot.


Maybe. I don't care, because it is entirely pointless to bring some American company before court (unless you have the money to pay your lawyer's flights to US).

Therefore, the much more important point is to choose carefully with whom I want to do business. And this is what I am talking about: "simply signing up" to github means no more and no less than declaring that I do want to do business with them. (And for that it doesn't matter if the fine-print would hold before court or not.)
And github (just like facebook, and amazon, etc.) is a company I certainly do NOT want to do business with - because I am rather choosy about that.


----------



## zirias@ (Dec 22, 2020)

Still pointless, cause THEY would have to bring YOU before court if you just don't pay.

So, if they ever want payment from you, they will make sure to communicate that in a way that's safe for them, IOW clearly inform and require action from your side to accept that. So, don't be paranoid here …

Anyways, whether you want to "trust" github or not has nothing to do with FreeBSD using GIT, cause they will use github only for a read-only mirror, which has already been there for a long time.


----------



## olli@ (Dec 22, 2020)

PMc said:


> Well, to my knowledge, projects managed in git are hosted on github.


No, there are quite many Git hosting services on the internet. GitHub might be the best known one, but there are many others. And of course you can run your own Git server locally if you want to.

The FreeBSD git repository is hosted by the FreeBSD project itself. It is mirrored to GitHub and GitLab, but this is purely for convenience. So, if GitHub goes away or changes its access policy in unacceptable ways, it will have no impact on FreeBSD itself whatsoever (except that those who access the repository via GitHub will have to switch over to somewhere else).

Personally I welcome the change from Subversion to Git. It improves collaboration and makes things easier for the developers, for example when several developers work on overlapping parts of the source tree. I expect code quality to improve, and of course reviews will still happen on Phabricator, which will even work better in combination with Git than it did with Subversion. This is all from the developers’ point of view, of course.

As far as users are concerned (i.e. non-developers), for 99 % of them there will be no change. freebsd-update(1) will continue to work. Those few who check out source code from the repository in order to “build world” will have to adapt their workflow, though, but it’s really not a big deal. Also, the author of net/svnup mentioned that he is working on a light-weight replacement that can be used with Git, so people who use svnup can switch over easily.

By the way, if everything else fails and you just want to get a source tree of -current or some other branch, you can download a .tar.gz of an arbitrary branch from cgit (these are generated on the fly). For this you don’t have to know how Git works at all.


----------



## kpedersen (Dec 22, 2020)

olli@ said:


> No, there are quite many Git hosting services on the internet. GitHub might be the best known one, but there are many others. And of course you can run your own Git server locally if you want to.


Absolutely true. However like those obsessed with Docker, it generally implies that they are really only interested in consuming from DockerHub. I don't think many would even know how to be self-sufficient and host their own server.

A little different with Git but I guess whatever server FreeBSD decides to host the repo on, they should just be prepared for an influx of "Why are you not using GitHub!? It is sooooo cool! You can have an avatar and everything!".

But yes, just because the direction of the most popular Git product is now governed by a bunch of dickheads less than trustworthy company, that shouldn't bias the decision based on the technical merits of Git... I suppose.

My biggest worry is that it now opens up FreeBSD to be abused by a bad element of the FOSS community who normally are kept away by the "complexity" of cvs, svn and mailing lists which would require some element of learning to interact with and something they tend to avoid. Though hopefully it will also attract many decent people too.


----------



## PMc (Dec 22, 2020)

Zirias said:


> Still pointless, cause THEY would have to bring YOU before court if you just don't pay.
> 
> So, if they ever want payment from you, they will make sure to communicate that in a way that's safe for them, IOW clearly inform and require action from your side to accept that. So, don't be paranoid here …



What makes You think I would have a *mental defect* just because I decide with whom I do business and with whom not?
Wasn't it always the fundamental right of the customer to decide if they want to do business with some counterparty?
Has this gone away? Are we now in China where everybody has to behave as BigBrother requires?


----------



## PMc (Dec 22, 2020)

olli@ said:


> As far as users are concerned (i.e. non-developers), for 99 % of them there will be no change. freebsd-update(1) will continue to work. Those few who check out source code from the repository in order to “build world” will have to adapt their workflow, though, but it’s really not a big deal.


I see. I for my part do not check out source code; instead I do apply my own secondary patchsets on top of the source code that is in SVN.  You can see this from my uname message:
FreeBSD 12.2-RELEASE-p2 #0 r368515M#N1130: Thu Dec 10 20:40:59 UTC 2020

This patchset (number 1130 in this case) is the collection of those fixes that are in `sendbug` waiting since 12 years for somebody to read them, among others. Therefore it is necessary that I do maintain these on my own.


----------



## olli@ (Dec 22, 2020)

PMc said:


> I see. I for my part do not check out source code; instead I do apply my own secondary patchsets on top of the source code that is in SVN.


I’m sorry, I don’t quite understand … Where do you get the source code from if you don’t check it out from SVN?


----------



## msplsh (Dec 22, 2020)

PMc said:


> You think I would have a *mental defect* just because I decide with whom I do business and with whom not?


Considering you can't stop talking about github when this thread isn't about github, the master repo isn't on github, and FreeBSD doesn't depend on github at all, maybe.


----------



## PMc (Dec 22, 2020)

olli@ said:


> I’m sorry, I don’t quite understand … Where do you get the source code from if you don’t check it out from SVN?


Hm, sorry, I forgot. It just works. Must look into the code.

So, at first it decides if to do `svn update` or `switch` (from the config, the date and other options).  It analyzes the result, and then decides upon a proper patchset, caring for jails and crossbuilds.
It then uses `svn patch` to apply the individual patches, verifies the result, requires interaction on conflicts, and finally uses `svn stat` and `svn diff` to store the state of affairs back into a new version of the patchset.
Finally `svn revert`, then the whole stuff is put into `zfs snapshot`, and that will be used for buildworld and portbuild.


----------



## olli@ (Dec 22, 2020)

PMc said:


> So, at first it decides if to do `svn update` or `switch` (from the config, the date and other options).  It analyzes the result, and then decides upon a proper patchset, caring for jails and crossbuilds.
> It then uses `svn patch` to apply the individual patches, verifies the result, requires interaction on conflicts, and finally uses `svn stat` and `svn diff` to store the state of affairs back into a new version of the patchset.


Ok, I see.
Actually I think that your workflow would work better with Git and a local clone of the repository. Git was designed to make it easy to maintain your own patchsets. Granted, there’s a certain learning curve, because Git works quite different from SVN (or CVS) in certain respects. But it is worth the effort, and there are several good introductions and tutorials on the web (Imp’s blog contains a few links).


----------



## a6h (Dec 22, 2020)

msplsh said:


> Considering you can't stop talking about github when this thread isn't about github, the master repo isn't on github, and FreeBSD doesn't depend on github at all, maybe.


You're right. Probably somebody has to create an off-topic threat for GitHub related discussions.
All that said, as a general rule, don't host materials on the GitHub, before reading its "Site Policy"


----------



## PMc (Dec 22, 2020)

olli@ said:


> Ok, I see.
> Actually I think that your workflow would work better with Git and a local clone of the repository. Git was designed to make it easy to maintain your own patchsets.


Yes, I was told that already, repeatedly. 
But then, this was some times after the switch CVS->SVN, and I had already a learning curve with SVN, and then I found SVN can be scripted, and so it is possible to do such things. It is nittypicky, and sometimes annoying, but finally the crap worked properly. And for a few years now there were only minor modifications (like introducing the flavors into ports) and I had finally all the problems solved (including those mismatching libraries from wrong ports/INDEX, and other nuisances).



olli@ said:


> Granted, there’s a certain learning curve, because Git works quite different from SVN (or CVS) in certain respects. But it is worth the effort, and there are several good introductions and tutorials on the web (Imp’s blog contains a few links).



So it basically boils down to what was my first assumtion already: at least for this part of it, I can just tear it down and write it anew. And, what is worse, I am forced to do that, in order to be able to stay current with security fixes.


----------



## zirias@ (Dec 22, 2020)

PMc said:


> What makes You think I would have a *mental defect* just because I decide with whom I do business and with whom not?
> Wasn't it always the fundamental right of the customer to decide if they want to do business with some counterparty?
> Has this gone away? Are we now in China where everybody has to behave as BigBrother requires?


Please don't do that, cause this is now far from any sane discussion. Just for the records, paranoia is not only used as a term for a "mental defect" but much more often for being afraid of things for close to no rational reasons, and it should be *pretty* clear. Furthermore, nobody ever forced you to register with github (which is NOT "doing business" as long as you use just their free services). Of course, if someone decides to have his issue tracker on github, you just can't use it in this case. I think this is a pretty simple thing to grasp. Again, this whole thing has nothing to do with FreeBSD, as FreeBSD sources are ALREADY mirrored on github and nothing will change. The "master" repository will not be on github.

As for Git: just get used to it. Having read now you maintain local changes, I do the same! And it was one of the reason I always wished for FreeBSD to finally move to Git, because THIS is one of the things that are just painless with Git (and not so much with Svn).


----------



## olli@ (Dec 22, 2020)

PMc said:


> So it basically boils down to what was my first assumtion already: at least for this part of it, I can just tear it down and write it anew. And, what is worse, I am forced to do that, in order to be able to stay current with security fixes.


 
Well, yes.  The world changes and people have to adapt.  This is the way.

Basically your workflow should continue to work for the lifetime of 12.x (the stable/12 branch). The release process of future 12.x versions (12.3 etc.) will still use SVN, and 13.0 will be the first release that will be built from Git. In other words, you’ll have to adapt to Git as soon as you want to switch over to 13.x.


----------



## PMc (Dec 22, 2020)

Zirias said:


> Please don't do that, cause this is now far from any sane discussion. Just for the records, paranoia is not only used as a term for a "mental defect" but much more often for being afraid of things for close to no rational reasons, and it should be *pretty* clear.



Yes, and You know the word "derogative", don't You? *eg*
It is about "group pressure": making people do "_what we all do_". This is fine for youth groups - but here it just serves for some extremely rich companies to create market dominance, because they explictely build upon this phenomenon.
And I think one should be conscious when participating in that game, because it is actually a way of advertising.



Zirias said:


> Furthermore, nobody ever forced you to register with github (which is NOT "doing business" as long as you use just their free services). Of course, if someone decides to have his issue tracker on github, you just can't use it in this case. I think this is a pretty simple thing to grasp.


Well, I can use their issue tracker very well, only they can't use my fixes, because they won't get them. It's a very simple thing to grasp: it doesn't hurt me at all, because I have the same work with fixing the crap in any case, and so I  just save the additional work of packaging the results in order to give them back to the community - and that's not my fault, because they are the ones who have decided to lock themselves up in an ivory-tower.


----------



## zirias@ (Dec 22, 2020)

What do you mean, a ghost driver? Thousands!

(and seriously, it's your decision to refuse registering an account with github. It's just obvious you can't make that look like a problem for the hundreds of thousands of projects using their free services. So YOU won't report issues or even submit patches? Well then, they probably won't care…)


----------



## PMc (Dec 22, 2020)

olli@ said:


> Basically your workflow should continue to work for the lifetime of 12.x (the stable/12 branch).


Great! That is good news for the src tree, and gives indeed ample time to adapt.

But what about the ports tree? I only found info that these will somehow be transferred at end of March21 - but couldn't find info about the cutover timeframe.


----------



## zirias@ (Dec 22, 2020)

PMc said:


> But what about the ports tree? I only found info that these will somehow be transferred at end of March21 - but couldn't find info about the cutover timeframe.


I'm reading that as the Q2 branch will be the last on SVN, but that's just interpretation. Would be interested as well. In fact, that's where I probably benefit the most, cause I do a LOT more changes on ports than on base


----------



## PMc (Dec 22, 2020)

Zirias said:


> What do you mean, a ghost driver? Thousands!


In German it would be "millionen Fliegen fressen ..."



> (and seriously, it's your decision to refuse registering an account with github. It's just obvious you can't make that look like a problem for the hundreds of thousands of projects using their free services. So YOU won't report issues or even submit patches? Well then, they probably won't care…)



Yes, and that doesn't matter to me, at all. But then, as is clearly stated in Liber Oz: "_The slaves shall serve_." (I also don't submit any more FreeBSD patches, as long as the old ones aren't processed.)

Furthermore, as was deliberately explained here, I could at any time set up my own git server and put the patched version onto that, in case somebody would want to use is.


----------



## PMc (Dec 22, 2020)

Zirias said:


> I'm reading that as the Q2 branch will be the last on SVN, but that's just interpretation. Would be interested as well. In fact, that's where I probably benefit the most, cause I do a LOT more changes on ports than on base


Well I rather hope to postpone this for a while - I have just yesterday decided to finally tackle the IPv6 matter, and that will probably require quite a bit of rewriting in my firewalling toolchain.


----------



## olli@ (Dec 22, 2020)

Zirias said:


> I'm reading that as the Q2 branch will be the last on SVN, but that's just interpretation. Would be interested as well. In fact, that's where I probably benefit the most, cause I do a LOT more changes on ports than on base


 
Quote from “Big Picture Overview of FreeBSD's git migration”:



End of March, 2021Ports repo slated to transition to git

_“The ports tree needs to make the switch just before a quarterly branch to avoid needing to mirror changes to subversion. Since there are a number of details to work out, they are planning to make the switch in March to allow time to consolidate their plans.”_

I’m reading that as the 21Q*1* branch will be the last on SVN, while 21Q2 (April) and onwards will be on Git.


----------



## jb_fvwm2 (Dec 22, 2020)

```
git clone https://git.FreeBSD.org/src.git -b stable/12 /usr/freebsd-src
```
 appeared to start the equivalent of an svn checkout to the last-parameter-destination, but I chose to halt the clone til I am further informed if it would only create the same amount of disk usage as the current /usr/src... as well as learning whether the stable/12 could be expanded to just clone a subset.


----------



## ljboiler (Dec 23, 2020)

I did this:
	
	



```
git clone -b stable/12 --depth 1 https://git.freebsd.org/freebsd/src.git src.git
```
I used `--depth 1` because I don't care about all the history; I just want the source code.  Without that, it takes a whole lot longer to download, but the result, currently, is smaller than the SVN equivalent.

Comparing the same stable/12 checked out from SVN:

```
root@lt1:/usr # du -sk /usr/src /usr/src.git
4180812 /usr/src
1723368 /usr/src.git
```

And no, there is no way to clone just a portion (subset) of a branch - it's all or nothing.


----------



## olli@ (Dec 23, 2020)

ljboiler said:


> ```
> root@lt1:/usr # du -sk /usr/src /usr/src.git
> 4180812 /usr/src
> 1723368 /usr/src.git
> ```


 
Not sure what’s in your /usr/src directory, but it should be a lot smaller. 
Here’s how it looks for me:

```
$ [b]git clone -b stable/12 --depth 1 https://git.freebsd.org/src.git /tmp/src-12-git[/b]
$ [b]du -ks /usr/src /tmp/src-12-git[/b]
   1·405·256  /usr/src
   1·682·332  /tmp/src-12-git
```
This result is expected. The above `git` command does two things: *First* it retrieves a so-called “shallow” copy of the repository that contains only the stable/12 branch without history information, i.e. only the “head” of that branch. The repository is compressed by default, so it doesn’t take too much space. It’s stored in the .git subdirectory:

```
$ [b]du -ks /tmp/src-12-git/.git[/b]
     293·033  /tmp/src-12-git/.git
```
*Second*, that `git` command checks out the actual source tree from the repository that was just retrieved. This is called a “work copy” in Git terms. As you can see, the total space used (~ 1650 MB) is the sum of the size of the usual source tree (~ 1370 MB) plus the size of the shallow repository for this particular branch (~ 280 MB).


----------



## Jose (Dec 23, 2020)

*Git is not Github. *This really needs to be emphasized. Linus himself is not a fan of Github.



olli@ said:


> No, there are quite many Git hosting services on the internet. GitHub might be the best known one, but there are many others. And of course you can run your own Git server locally if you want to.


And all you need to set up your own server is two machines with ssh access. There's really no concept of client and server in git(1), but let's call the machines "workstation" and "server" for clarity.

On the workstation you'd do something like

```
mkdir myrepo
cd myrepo
git init
vi foo.txt
git add foo.txt                                              
git commit -m "Foo is important"
```
You now have a local Git repo. Set it up on the server like this

```
git clone --bare ssh://workstation/~/myrepo
```
Now you have a complete copy of myrepo with all history, etc. on the server. However, due to the distributed-by-default nature of Git, the workstation is not connected to the server in any way. Let's connect it. On the workstation you'd do

```
git remote add origin ssh://server/~/myrepo
git push -u origin master
Branch 'master' set up to track remote branch 'master' from 'origin'.
Everything up-to-date
```
Now any time you git-push(1) your changes will be uploaded to server.


----------



## zirias@ (Dec 23, 2020)

Jose said:


> *Git is not Github. *This really needs to be emphasized. Linus himself is not a fan of Github.


Although I like github (and similar services and also similar software for on-premise installation) for the nice extra features they provide (and I couldn't care less what Linus thinks about that)…

Yes indeed, this misconception "GIT == github" is astonishing and somewhat alarming.
Reminds a bit of the "www == internet" misconception :/

I also have a few "bare" repos on my server with no additional software, just plain Git. And sure, they work well.


----------



## CyberCr33p (Dec 25, 2020)

olli@ said:


> Also, the author of net/svnup mentioned that he is working on a light-weight replacement that can be used with Git, so people who use svnup can switch over easily.











						GitHub - johnmehr/gitup: A minimalist, dependency-free FreeBSD program to clone/pull Git repositories.
					

A minimalist, dependency-free FreeBSD program to clone/pull Git repositories. - GitHub - johnmehr/gitup: A minimalist, dependency-free FreeBSD program to clone/pull Git repositories.




					github.com


----------



## ucomp (Dec 26, 2020)

Zirias said:


> ...Of course, if your project is NOT opensource, using github for it would require payment, and probably most companies use their own infrastructure instead.....


you can create private repo(e.g. fork FreeBSD into it) in GitHub for no cost  and invite collaborators(which have a GitHub-account). afaik you also can in gitlab. there are paid services although I didn't get to the moment where I would need them(probably depends on size of project, `don't know).
at the moment freebsd`s GitHub-master-repo is out of sync with main-repo of fbsd`s own git-server because of incompatible hashes.
..
so, to say a bit clearer: as state of today /Dec/26/2020
https://github.com/freebsd/freebsd master branch
is out of sync   
with https://git.FreeBSD.org 

 while 









						FreeBSD / FreeBSD src · GitLab
					

Mirror of the FreeBSD source tree




					gitlab.com
				



is in sync with 
https://git.FreeBSD.org 

so if one forks or clone freebsd-src you won't start with GitHub today(/Dec/26/2020).


----------



## ucomp (Dec 27, 2020)

ucomp said:


> .. so if one forks or clone freebsd-src you won't start with GitHub today(/Dec/26/2020)....


while it's possible to create your own GitHub mirror of src-main-tree TODAY (I did it like that), I guess that's only for us impatient  who really rely on compiling  with it right away.

while 








						GitHub - freebsd/freebsd-doc: FreeBSD doc tree (read-only mirror)
					

FreeBSD doc tree (read-only mirror). Contribute to freebsd/freebsd-doc development by creating an account on GitHub.




					github.com
				



is already on sync, I was told that the src-main-repo will come to GitHub the next days(perhaps minutes, perhaps seconds, who knows;-)


----------



## rigoletto@ (Dec 27, 2020)

The mirror exist on GitHub since years already. The one on GitLab that is new.


----------



## a6h (Dec 27, 2020)

Also there's one on Codeberg:









						The FreeBSD Project
					

Codeberg is founded as a Non-Profit Organization, with the objective to give the Open-Source code that is running our world a safe and friendly home, and to ensure that free code remains free and secure forever.




					codeberg.org


----------



## ucomp (Dec 27, 2020)

rigoletto@ said:


> The mirror exist on GitHub since years already. The one on GitLab that is new.


the GitHub - mirror is out of sync .
while
Gitlab is on sync.
the old GitHub master branch will not be updated no more,
it was the import of SVN and lwhsu made the last commit to it.
the new branch is called *main* whereas the old GitHub was called *master.*
So as long as there is no branch called *main *on Github, it's out of sync.


----------



## rigoletto@ (Dec 27, 2020)

ucomp said:


> the GitHub - mirror is out of sync .
> while
> Gitlab is on sync.
> the old GitHub master branch will not be updated no more,
> ...


Hmm...


----------



## ucomp (Dec 27, 2020)

vigole said:


> Also there's one on Codeberg:


I even have my own on GitHub but I would recommend gitlab as a trusted source for everybody  as state of today


rigoletto@ said:


> Hmm...


 yes it's true, 'master is dead, long live main'


----------



## rigoletto@ (Dec 27, 2020)

ucomp

I just asked @lwhsu and he told me there are some TODOs before syncing with GitHub, and this (GitHub) issue is likely to be resolved next week.


----------



## ucomp (Dec 27, 2020)

rigoletto@ said:


> ucomp
> 
> I just asked @lwhsu and he told me there are some TODOs before syncing with GitHub, and this (GitHub) issue is likely to be resolved next week.


yes, I was also told that it will be solved but we can use gitlab today and I doubt that *main* will be "pluggable" into master and even would make no sense to confuse branch names. So rebasing seems a must (for those who used the master-branch in the past)


----------



## rigoletto@ (Dec 27, 2020)

ucomp said:


> yes, I was also told that it will be solved but we can use gitlab today and I doubt that *main* will be "pluggable" into master and even would make no sense to confuse branch names. So rebasing seems a must (for those who used the master-branch in the past)


I've been using the GitLab one since it is considerably faster for me.

*[EDIT]* Btw, the JetBrains Space looks kinda cool.


----------



## ucomp (Dec 27, 2020)

rigoletto@ said:


> I've been using the GitLab one since it is considerably faster for me.
> 
> *[EDIT]* Btw, the JetBrains Space looks kinda cool.


`made my GitHub-src-mirror with gitlab, was a one-click-thing, not bad.
jetbrainsSpace really looks interesting and feature-rich, similar pricing like gitlab incl. Free-plan, maybe an idea for you to open up a freebsd-official account on JetBrains-space?


----------



## rigoletto@ (Dec 28, 2020)

ucomp said:


> `made my GitHub-src-mirror with gitlab, was a one-click-thing, not bad.
> jetbrainsSpace really looks interesting and feature-rich, similar pricing like gitlab incl. Free-plan, maybe an idea for you to open up a freebsd-official account on JetBrains-space?


I suppose there is no enough space quota on Free for everything FreeBSD, similar to Bitbucket.


----------



## ucomp (Dec 28, 2020)

rigoletto@ said:


> I suppose there is no enough space quota on Free for everything FreeBSD, similar to Bitbucket.


true, they don't for free : https://www.jetbrains.com/community/opensource/#support
whereas gitlab seems to do, if I understand correctly  :





						GitLab for Open Source
					

Open source communities benefit from the one DevOps platform.




					about.gitlab.com
				



currently afaik FreeBSD doesn't use Enterprise features on gitlab, I could see that because of missing (smaller) features when logged in.


----------



## rigoletto@ (Dec 28, 2020)

ucomp said:


> true, they don't for free : https://www.jetbrains.com/community/opensource/#support
> whereas gitlab seems to do, if I understand correctly  :
> 
> 
> ...


I created an account on Space and at least on the Free version there is no way to make a repository public (probably possible on premises). This is quite Corporation focused - nice for internal use.


----------



## ucomp (Dec 28, 2020)

rigoletto@ said:


> I created an account on Space and at least on the Free version there is no way to make a repository public (probably possible on premises). This is quite Corporation focused - nice for internal use.


yeh, it's actually a pity, that jetbrains has to make a living exclusively of per-user-fees. yes,they plan 'on premise' but I`m quite sure: only with license fees.I was surprised about gitlab , multiple mirror- setups,private/public, all for free.... 
by the way, your friend has set the old *master* to the attik:
https://github.com/freebsd/freebsd-legacy .
..e.g with gitlab it were a one-click to setup a the new *main*-mirror to GitHub... so new gitHub-mirror will come soon I guess.


----------



## geos (Dec 28, 2020)

Hello 
This article came to my attention about GitHub and would like to share it with you. I have red some other articles of this guy and seems to know what he is talking about (security etc.) Anyway you decide.... https://sneak.berlin/20200307/the-case-against-microsoft-and-github/


----------



## ralphbsz (Dec 28, 2020)

This guy does not know what he's talking about, at least not always. Example: His use of Edward Snowden's PRISM slide. He claims that Microsoft and many other providers have cooperated with the NSA and provided data to the NSA, and singles out Microsoft for particular scorn as having been the first one. This statement is false. What really happened is that starting in the early 2000s, the NSA (and presumable other agencies, in particular in countries other than the US) tapped communications lines within the systems of the large providers (often with the willing help of telecommunications companies, AT&T in particular), and were able to obtain content from the providers such as Microsoft (hotmail!) without their consent.

If you follow his advice to not do business with any company that supplies the US military, US intelligence agencies, or the US immigration system, you might as well become Robinson Crusoe and move to an island by yourself.

And all this discussion about GitHub is pointless anyway. The FreeBSD source control system doesn't rely on GitHub, it just places a copy of the source code on GitHub. Given that FreeBSD is freely distributable, anyone else can download the source code and place it on GitHub themselves, as long as they leave the copyright notice intact.


----------



## PMc (Dec 28, 2020)

ralphbsz said:


> This guy does not know what he's talking about, at least not always.


This does not even deserve a differenciated critique. Only 20 years ago it would have been dismissed rightaway, or attributed to some extremist fanatics - but nowadays, well, it's Berlin. Berlin seems to attract all kind of that ilk, maybe because the reigning governement there is the shining role model for such imbecility.



ralphbsz said:


> If you follow his advice to not do business with any company that supplies the US military, US intelligence agencies, or the US immigration system, you might as well become Robinson Crusoe and move to an island by yourself.


That's the problem with these hipsters. They have some highly ambitions ethical ideals which they violently propagate, while at the same time themselves living a life full of contradictions to their ideals - and it doesn't matter to them, because they grew up getting spoon-fed with everything and never needed to take any kind of personal responsibility.


----------



## a6h (Dec 28, 2020)

I don't want to down play the role of computer security experts in our society. It's real job, real title, but very rare. It's a complicated business. It demands vast amount of skills, experience and intelligence. The last one is the tough one. It's more a biologic matter. Very similar to game developers. I'm not talking about Unity-kiddies. The real ones. John Carmack come into my mind. You have to be polymath. You can't just learn to code, or pay to learn.

Once upon of time, we had computer security expert inflation. They were all over place. It was a cool title. Men like titles. Not in this case, but generally titles maybe improve their chance of getting a date. Most of them have moved on. They are SEO expert now. Some of them are still on the job, spreading nonsense.

Many years ago, a random clown (raw socket hater) on the internet, accused Microsoft of deliberately putting WMF vulnerability into Windows. He was roasted a few days later. He's still around. Dude is a podcaster now. Typical! These are your typical security bloggers and experts. Generally it's better to ignore them all together.


----------



## ucomp (Dec 29, 2020)

PMc said:


> ....maybe because the reigning governement there is the shining role model for such imbecility.




I would have a better example
 for an `imbecility`- role-model : 
spamming  a technical git-conversion-thread  with  
e.g. SEO-links to imbecility-reports and never stopping talking about things which have absolutely nothing to do with git.
Nothing against free speech but at this level it is impossible to go into FreeBSD details.

I don't care, not my forum and everyone can do what they want, I never say others what they have to do and I make mistakes too
, but you don't do anybody a favor by destroying discussions with political crap. just my few cents.

sorry for the clarity


----------



## fel1x (Dec 29, 2020)

Finally! I'm very delighted that FreeBSD Project now use Git. I hope more developers participate this project!


----------



## geos (Dec 29, 2020)

ucomp said:


> spamming a technical git-conversion-thread with
> e.g. SEO-links to imbecility-reports


I'm not a spammer nor into politics and i don't care about government business. I posted, because i wanted to hear some other thoughts about security(of course technical matter)  of Github and MS involvement in Github.  Ralphbsz's answer "Given that FreeBSD is freely distributable, anyone else can download the source code and place it on GitHub themselves, as long as they leave the copyright notice intact. " makes some sense. Didn't mean to upset your conversation..maybe i should have opened another thread.


----------



## ucomp (Dec 29, 2020)

geos said:


> ...... *anyone *else can download the source code and place it on GitHub themselves, ...


I'm quite sure that as good as* no one * of the interested git-newcomers here did understand how to " download and place"(  ) src on GitHub or anywhere else  today.
you can guess 3 times why that is.
are you interested in compiling the FreeBSD source code ?
if yes, , please try it out ,
I'm taking a first hint: it's not called " download and place", 
it's called *fork, clone or mirror .*


----------



## olli@ (Dec 29, 2020)

ucomp said:


> I'm taking a first hint: it's not called " download and place",
> it's called *fork, clone or mirror .*


He was using more generic terms, because FreeBSD’s license allows exactly that: downloading the code and placing it somewhere else, whether it be GitHub, a P2P network or an FTP server. In Git terms this is called “cloning”, but basically it also boils down to downloading data from one machine and placing it on another machine.


----------



## ucomp (Dec 29, 2020)

olli@ said:


> ... a P2P network ...


first entry is FreeBSD 9.0 on https://thepiratebay.org/search.php?q=freebsd&all=on&search=Pirate+Search&page=0&orderby=  ,
yeah, I guess that's the way to go   ...just kidding..



olli@ said:


> ....FTP server....


yeah, that's an  interesting choice ( not kidding this time).
there's a special FTP called TFTP.
are you willing to explain to user `geos' in which case it could be interesting to *download and place* ;-)  *src(*-images*)* exactly there ?


olli@ said:


> ... but basically it also boils down to downloading data from one machine and placing it on another machine.


....or with git from one machine or many machines  to thousands of other machines...

Regards


----------



## olli@ (Dec 29, 2020)

ucomp said:


> there's a special FTP called TFTP.


Wrong, TFTP is not a special variant of FTP. They have little in common. But that’s irrelevant for this topic anyway.
 


> are you willing to explain to user `geos' in which case it could be interesting to *download and place* ;-)  *src(*-images*)* exactly there ?


In fact FreeBSD (source and binaries) _is_ available from many FTP servers.
 
But what is your point exactly? Maybe you should read again what ralphbsz wrote, because I think you didn’t get his point, even though you quote him again and again.


----------



## ucomp (Dec 29, 2020)

olli@ said:


> Maybe you should read again what ralphbsz wrote, because I think you didn’t get his point, even though you quote him again and again.


I think we're talking past each other,
I haven't even read oder answered  
 ralphbsz`s posts, what do you mean with "I quote him" ??? no clue what you mean ...did I click a quote-button accidentally or so?, no clue 



olli@ said:


> TFTP is not a special variant of FTP. They have little in common. But that’s irrelevant for this topic anyway.
> 
> In fact FreeBSD (source and binaries) _is_ available from many FTP servers.
> 
> But *what is your point exactly?*


I thought you knew what *TFTP* has to do with *compiled kernel-images *
and thought that perhaps you were interested in talking about git, compiling src 
and what we do with it. So *that was my point,* my point was not comparing the difference of FTP to TFTP-protocol details.
--
so, misunderstandings aside, and for the interested:
 TFTP is e.g. used for netbooting compiled kernel images.


----------



## olli@ (Dec 29, 2020)

ucomp said:


> I think we're talking past each other,
> I haven't even read oder answered
> ralphbsz`s posts, what do you mean with "I quote him" ??? no clue what you mean ...did I click a quote-button accidentally or so?, no clue


You keep trying to dispute the words “download and place” – these are ralphbsz’s words.
 
I _do_ know what TFTP is.  I started using it 30 years ago for booting Emulex terminal servers.
But I _don’t_ know how it would be relevant to this thread. It has nothing to do with Git, or with distributing FreeBSD code.  If you want to talk about TFTP, you should open a new thread.


----------



## ucomp (Dec 29, 2020)

olli@ said:


> You keep trying to dispute the words “download and place” – these are ralphbsz’s words.


phew, aha, now I know what you mean(after reading Ralph`s post exactly) really didn't see that ralphbsz is the inventor of "download and place” 


olli@ said:


> It has nothing to do with Git, or with distributing FreeBSD code.  If you want to talk about TFTP, you should open a new thread.


while I compile and boot mostly from disks , I think netboot has a lot to do with distributing FreeBSD code(on the local network).
also used emulex fc-cards in the past... while I remember on one server I had to replace one with an qlogic because of missing emulex-driver.
And ,No: don`t want to talk about anything like tftp here no more , 
the climate here seems too poisoned and unfocused
(sure not your fault),

nothing bad,
and maybe meet you sometime here again,
until then take care
Regards


----------



## Jose (Dec 30, 2020)

ucomp said:


> so, to say a bit clearer: as state of today /Dec/26/2020
> https://github.com/freebsd/freebsd master branch
> is out of sync
> with https://git.FreeBSD.org
> ...





vigole said:


> Also there's one on Codeberg:
> 
> 
> 
> ...


Why limit ourselves to one mirror? Let's collect them all!

First clone the canonical repo so it gets set up as our `origin`

```
time git clone https://git.freebsd.org/src.git                                                           
Cloning into 'src'...
remote: Enumerating objects: 377603, done.
remote: Counting objects: 100% (377603/377603), done.
remote: Compressing objects: 100% (26669/26669), done.
remote: Total 3819016 (delta 371845), reused 350928 (delta 350928), pack-reused 3441413
Receiving objects: 100% (3819016/3819016), 1.13 GiB | 24.16 MiB/s, done.
Resolving deltas: 100% (3024229/3024229), done.
Updating files: 100% (81247/81247), done.
    2m22.19s real     3m45.89s user     0m13.99s system
```

Now let's add Coderberg and fetch its state

```
cd src
git remote add berg https://codeberg.org/FreeBSD/freebsd-src.git
git fetch berg
From https://codeberg.org/FreeBSD/freebsd-src
 * [new branch]              main                             -> berg/main
 * [new branch]              releng/1                         -> berg/releng/1
 * [new branch]              releng/10.0                      -> berg/releng/10.0
 * [new branch]              releng/10.1                      -> berg/releng/10.1
 * [new branch]              releng/10.2                      -> berg/releng/10.2
 * [new branch]              releng/10.3                      -> berg/releng/10.3
 * [new branch]              releng/10.4                      -> berg/releng/10.4
...
```

Let's check whether the canonical main branch and the Coderberg main branch are the same

```
git diff ..berg/main
diff --git a/sys/arm/arm/pmu.c b/sys/arm/arm/pmu.c
index 544962e9ab2..b16ffcafcfa 100644
--- a/sys/arm/arm/pmu.c
+++ b/sys/arm/arm/pmu.c
@@ -36,6 +36,7 @@
 __FBSDID("$FreeBSD$");
 
 #include "opt_hwpmc_hooks.h"
+#include "opt_platform.h"
 
 #include <sys/param.h>
 #include <sys/systm.h>
@@ -49,14 +50,31 @@ __FBSDID("$FreeBSD$");
 #include <sys/pmc.h>
 #include <sys/pmckern.h>
 
+#ifdef FDT
+#include <dev/ofw/openfirm.h>
+#include <dev/ofw/ofw_bus.h>
+#include <dev/ofw/ofw_bus_subr.h>
+#endif
+
 #include <machine/bus.h>
...
```
Hm, maybe the Coderberg mirror is a little behind? Let's add Gitlab and check

```
git remote add gitlab https://gitlab.com/FreeBSD/freebsd-src.git
git fetch gitlab
remote: Enumerating objects: 38377, done.
remote: Counting objects: 100% (38377/38377), done.
remote: Total 294744 (delta 38377), reused 38377 (delta 38377), pack-reused 256367
Receiving objects: 100% (294744/294744), 62.01 MiB | 11.28 MiB/s, done.
Resolving deltas: 100% (82379/82379), completed with 36987 local objects.
From https://gitlab.com/FreeBSD/freebsd-src
 * [new branch]              main                             -> gitlab/main
 * [new branch]              master                           -> gitlab/master
 * [new branch]              releng/1                         -> gitlab/releng/1
 * [new branch]              releng/10.0                      -> gitlab/releng/10.0
 * [new branch]              releng/10.1                      -> gitlab/releng/10.1
 * [new branch]              releng/10.2                      -> gitlab/releng/10.2
 * [new branch]              releng/10.3                      -> gitlab/releng/10.3
 * [new branch]              releng/10.4                      -> gitlab/releng/10.4
...
git diff ..gitlab/main                                                                               
$
```
Yep, it looks like Coderberg is a little behind. Adding the Github remote and checking what the difference is between the canonical main branch and the Github master branch are left as exercises for the reader.


----------



## ralphbsz (Dec 31, 2020)

I have a really dumb question. The official git repo for FreeBSD is hosted on a set of machines under control of the FreeBSD project, with host names like {cgit,repo,git}.freebsd.org. Those seem to be working fine. They seem to have a geographically spread DNS infrastructure in place, so they should be pretty close to people (mine is within the US). Why does anyone even bother with the read-only mirrors at places like github and gitlab? Why are we even arguing over those? Why don't we just completely ignore them?


----------



## shkhln (Dec 31, 2020)

ralphbsz said:


> Why don't we just completely ignore them?


GitHub has a really convenient web UI for casual source code reading. I have no idea why would anyone bother with GitLab, that thing is insufferable.


----------



## Jose (Dec 31, 2020)

You certainly don't have to, and I probably will not use any of the mirrors. One convenient thing Git{hub,lab} can do for you is host a remote clone. Github calls these "forks" and they have an easy Web UI for creating them. You would want a remote clone as a backup of any changes you made and also because most of us won't have write access to the canonical Freebsd repos and thus won't be able to push changes to them.



shkhln said:


> GitHub has a really convenient web UI for casual source code reading. I have no idea why would anyone bother with GitLab, that thing is insufferable.


The Gitlab browser works well enough for me, but I'm not particularly picky about that kind of thing. Is there something specific that bugs you about the interface?

Gitlab started life as an open-source clone of Github back in the day when Github's on-premises "product" was a sick joke. They used to be very, very similar. I haven't really kept up with how they've changed.


----------



## shkhln (Dec 31, 2020)

Jose said:


> The Gitlab browser works well enough for me, but I'm not particularly picky about that kind of thing. Is there something specific that bugs you about the interface?


Clutter, low contrast (in menus), slowness. I don't have the same reaction to Bitbucket for example, so it's not like I can't tolerate any alternatives.

Compare https://gitlab.com/FreeBSD/freebsd-...d1f1152e532ff7b489f7c/libexec/rtld-elf/rtld.c with https://github.com/freebsd/freebsd-src/blame/main/libexec/rtld-elf/rtld.c. GitLab has an obnoxious overhanging panel at the top of the page, a side bar I don't care about and the commit descriptions taking 3 (code) lines of height, which looks annoying when they correspond to only one line of code.


----------



## mickey (Dec 31, 2020)

Just wondering about the disk space usage... Previously I had used `svnsync` to maintain an on-premises mirror of the FreeBSD src SVN repository which was using over 7 GiB on an lz4 compressed ZFS dataset. Now after mirroring the GIT repository it only uses about 1.3 GiB. Not that I don't appreciate the extra disk space, but ... how comes?


----------



## ucomp (Dec 31, 2020)

ralphbsz said:


> I have a really dumb question.


no, opposite of dumb, that's the first reasonable question I read here here, namely the one it's about   :



ralphbsz said:


> Why does anyone even bother with the read-only mirrors at places like github and gitlab?


O.K.,
first we should explain the term *mirror *compared to a *fork.*

A *fork* is first a *onetime-download&place*( *(c) 2020 ralphbsz* ),... couldn't resist.. ..
it initializes the hashes which will then be manually download&place(!) again and again with the command : `git pull`

while

a *mirror* is not a onetime thing, it is instead a *stream* which automatically
updates the source tree e.g. every 5 minutes or whatever count of minutes.

now to the term *read-only* mirror :
when you* fork from a mirror* of the original git-server  @freebsd.org
e.g. to  YOUR(!!!) *GitHub*-account that will* NOT* (!!!) be a *read only* mirror.
So you  would first fork from @freebsd.org , setup that fork to point a
mirror of itself to  your GitHub-account to which then you will have
*read&write*-access.
and that  will be your *origin *to your local(or remote-) machine(s !!!).

So the '*HUB'* in the name GitHub has reason.

the answer to your excellent question is:
we don't bother with readonly mirrors, instead we mirror e.g. to GitHub
to make it *read&WRITE*.


this example of a setup has good reasons for developers, but since no one has asked why,
that's another thing because I have become cautious about answering question which were not asked ;-)

Regards


----------



## ucomp (Dec 31, 2020)

so, as described above & to shine a light on all that GitHub -thing:

*GitHub* is the *HUB* which serves as (code-)*origin* to your local(or remote) machine(s).

same as your *USB-Hub* serves your local USB-gadgets,.

GitHub distributes code , your USB-Hub distributes devices.

while you can use the web-fronted of GitHub that's not the reason for using it.
the reason is pull&push( and some other things).

... as gitlab does(but nobody asked about the differences ;-)


----------



## ucomp (Dec 31, 2020)

the main-branch -mirror  is now on GitHub, as I just saw :








						GitHub - freebsd/freebsd-src: FreeBSD src tree (read-only mirror)
					

FreeBSD src tree (read-only mirror). Contribute to freebsd/freebsd-src development by creating an account on GitHub.




					github.com
				



(it was called master-branch before, which is now obsolete and archived). 

for those not yet familiar with it:
main == FreeBSD13 , you will also see e.g branches : 
stable/12
and 
stable/11
on GitHub.


----------



## msplsh (Dec 31, 2020)

ralphbsz said:


> I have a really dumb question. ... Why does anyone even bother with the read-only mirrors at places like github and gitlab?


Because some people like those places.  Some people do not.



ralphbsz said:


> Why are we even arguing over those?


Because other people want everyone to know about their crusade against things they don't like.



ralphbsz said:


> Why don't we just completely ignore them?


That's what a completely rational person would do if they didn't like those services, didn't need them to continue operating, and considered them to not be a threat to the service they were using.


----------



## Jose (Dec 31, 2020)

ucomp said:


> *GitHub* is the *HUB*...


Git has no concept of hubs or spokes. All repositories are stand-alone, completely independent peers.


ucomp said:


> ...which serves as (code-)*origin* to your local(or remote) machine(s).


You *DO NOT HAVE TO USE GITHUB. *You can clone any of the mirrors or the canonical repository as I have shown above. There's really no sense in cloning one of the mirrors, as Ralphbsz points out. Why would you risk using a stale copy?

Furthermore, there's nothing special about the remote called "origin":
"Just like the branch name 'master' does not have any special meaning in Git, neither does 'origin'. While 'master' is the default name for a starting branch when you run git init which is the only reason it’s widely used, 'origin' is the default name for a remote when you run git clone. If you run git clone -o booyah instead, then you will have booyah/master as your default remote branch."





						Git - Remote Branches
					






					git-scm.com
				




You don't have to have a remote called "origin" if you don't want to. You can change the URL for the "origin" remote at any time. Git really is distributed and really doesn't care.


ucomp said:


> while you can use the web-fronted of GitHub that's not the reason for using it.
> the reason is pull&push( and some other things).


Push and pull are standard Git functionality. They have absolutely nothing to do with Github.


ucomp said:


> ...it initializes the hashes which will then be manually download&place(!) again and again with the command : `git pull`


Commit hashes are a function of the state of the tree at a particular change set. They are completely independent of how or where the repository is hosted, and are calculated when git-commit(1) runs, not when the repository is cloned or when git-pull(1) is invoked. The default mechanism for a git pull is a git-fetch(1) followed by a git-merge(1). The merge might create a merge commit depending on your settings, and this would create a new hash (it is a commit, after all). Existing hashes would not be affected.


msplsh said:


> Because other people want everyone to know about their crusade against things they don't like.
> 
> That's what a completely rational person would do if they didn't like those services, didn't need them to continue operating, and considered them to not be a threat to the service they were using.


Like or dislike has nothing to do with it. I want to dispel the notion that Git and Github are the same thing. I don't want anyone to think that you have to use Github to access the Freebsd source. I can see why reasonable people would have a problem with contributing freely to a project beholden to a for-profit company.


----------



## ucomp (Dec 31, 2020)

Jose said:


> Git has no concept of hubs or spokes. All repositories are stand-alone, completely independent peers.
> 
> You *DO NOT HAVE TO USE GITHUB. * There's really no sense in cloning one of the mirrors, as Ralphbsz points out. Why would you risk using a stale copy?
> 
> o.k, let`s shine light on this things:


1st: correct: *nobody is forced *to use GitHub to work with git, I thought that was one of the really few things which were often enough cleared up here .

but
*everybody can* use GitHub, like millions others do (or gitlab or an own server like freebsd.org) .
---



Jose said:


> There's really no sense in *cloning *one of the mirrors, as Ralphbsz points out. Why would you risk using a stale copy?


it's the opposite in my example above:
I do not clone the fbsd-GitHub-mirror. Instead I setup my fbsd-GitHub-repo as an fbsd-mirror .
why? simple answer : no more need of `git pull(upstream)/git push(MYorigin)` to the GitHub-repo. So it's *NOT a clone* nor a fork, it's a mirror (which can than be cloned to everywhere). but why? because it`s then a read/write mirror instead of readonly.
( while technically a mirror is NEVER readonly because the main thing it does is write and write and write and...)



Jose said:


> .....
> Furthermore, there's nothing special about the remote called "origin":
> "Just like the branch name 'master' does not have any special meaning in Git, neither does 'origin'. While 'master' is the default name for a starting branch when you run git init which is the only reason it’s widely used, 'origin' is the default name for a remote when you run git clone. If you run git clone -o booyah instead, then you will have booyah/master as your default remote branch."
> 
> ...


yes, that's all correct and a confusing detail for newcomers:
git doesn't care about names,

you even can fork FreeBSD on Github and call it OpenBSD-src 

but why are those names widely used and we use it here :
because we can try to talk about the same when we use terms like remote, upstream, origin, fork, clone and so on...



Jose said:


> Push and pull are standard Git functionality. They have absolutely nothing to do with Github.
> 
> Commit hashes are a function of the state of the tree at a particular change set. They are completely independent of how or where the repository is hosted, and are calculated when git-commit(1) runs, not when the repository is cloned or when git-pull(1) is invoked. The default mechanism for a git pull is a git-fetch(1) followed by a git-merge(1). The merge might create a merge commit depending on your settings, and this would create a new hash (it is a commit, after all). Existing hashes would not be affected.


absolutely right



Jose said:


> I can see why reasonable people would have a problem with contributing freely to a project beholden to a for-profit company.


not worth to talk about it because that implies that people who contribute to or use GitHub 
were not reasonable.
that's all only Blabla . we have e.g. developed openjdk bsd-port on GitHub .
boah , we must have been really unreasonable, so let's delete the openjdk-port from FreeBSD 
because we have political incorrectly ran with the devil 
what a f*cked up crap-discussion, let's stay technical ;-) 


Have a good new year!

Regards


----------



## msplsh (Dec 31, 2020)

Jose said:


> I want to dispel the notion that Git and Github are the same thing


Fair.  People seem to have _*serious*_ problems with this.


Jose said:


> I can see why reasonable people would have a problem with contributing freely to a project beholden to a for-profit company.


Ok, but there's no contribution going on here.  Just use.  Nobody cares about other people's problems that can be solved by the other person ignoring the thing that is bothering them with zero consequences for doing so.


----------



## ucomp (Dec 31, 2020)

msplsh said:


> ...Just use.  Nobody cares about other people's problems ....


you haven't asked me   but I clicked `reply` because something of what you say sounds sad.

But we don't have to be so sad today ;-)...

just NOT use wouldn't  be the same as take care about other people`s problems ,


So there should be room for improvement in terms of compassion for other people`s problems, even though we(whoever that is) are using GitHub ;-)

by the way, I used google-translator for this post, beholden to a for-profit company,
please forgive me  

Have a good new year!

Regards


----------



## msplsh (Dec 31, 2020)

ucomp said:


> So there should be room for improvement in terms of compassion for other people`s problems


You didn't finish the quote.

If people can solve their problem by ignoring something (github), then they should do that.  If ignoring something (github) is a zero-consequence action, I can't think of a reason why they should not ignore the thing (github).  It's a self-inflicted problem if they won't ignore it (github) so there is little room for compassion.


----------



## Jose (Dec 31, 2020)

msplsh said:


> Ok, but there's no contribution going on here.  Just use.  Nobody cares about other people's problems that can be solved by the other person ignoring the thing that is bothering them with zero consequences for doing so.


I care if other people's problem with Github is going to prevent them from contributing because they have been led to believe that "Freebsd is using Git" means "You have to use Github to contribute to Freebsd".


ucomp said:


> ...no more need of `git pull(upstream)/git push(MYorigin)` to the GitHub-repo...


What happens when you push to the main branch of your mirror? Your version of the main branch diverges from the main branch of the canonical repo. The next time you `git rebase main` you might get clean results that are spurious, and your pull request against the canonical main branch might be rejected because of conflicts you can't even see.


ucomp said:


> not worth to talk about it because that implies that people who contribute to or use GitHub
> were not reasonable.


Absolutely does not imply that in any way, but let me be forcefully clear. I have absolutely no problem with anyone using Github, and have used it myself to contribute to projects that are hosted there exclusively. However, many people I respect would refuse to make open-source contributions to any scheme that had any kind of for-profit angle. They would expect to be paid for that, and handsomely.

I have a big problem with making people believe that they're forced to use Github to contribute to Freebsd. It's simply not true, and probably counterproductive. Yes, I'm going to keep repeating this.


----------



## msplsh (Dec 31, 2020)

Jose said:


> I care if other people's problem with Github is going to prevent them from contributing because they have been led to believe that "Freebsd is using Git" means "You have to use Github to contribute to Freebsd".


Also fair.  If they won't believe you after you explain it to them over and over, the value of their contributions might come into question.


----------



## ucomp (Jan 1, 2021)

Jose said:


> ......





msplsh said:


> .....


Olè guys and happy new year !
I now have read yours link and statements to the YouTube-dl-thing... : so it wasn't GitHub`s idea
to remove the dl-repo and Instead they were forced by another company to remove it? did I understand that correctly?
So instead of blaming GitHub we now have to stop watching YouTube? is that a correct analysis? ;-)
if so, that's good news, so instead of watching videos the whole day we can
browse and learn understanding parts of FreeBSD-src and edit code on GitHub,
The world changes to a better place  Ha Ha

And don't forget:
You are *totally forced *to use GitHub because FreeBSD`s web-frontend is so ugly and lacks functionality  Ha Ha

for those who have read the FreeBSD source code and then realize that the  problems of the human race are far greater than they could ever imagine  :
please don’t worry, you are *not forced* to use GitHub, instead you can feel free to get back
to YouTube  e.g to watch a good Clint Eastwood-western , catched by YouTube-dl .

-- ah, forgot: ---


Jose said:


> What happens when you push to the main branch of your mirror? Your version of the main branch diverges from the main branch of the canonical repo. The next time you `git rebase main` you might get clean results that are spurious, and your pull request against the canonical main branch might be rejected because of conflicts you can't even see.


while good point what you say, there's no problem for me  with, because I fork the mirror again to a place where I can do every possible chaos of code  without breaking something...that's the comfortable thing with those "HUBs", you can do a lot with some clicks as long as you know what you're doing.


Jose said:


> .....pull request .......


I was amazed that no one has gone into it so far, so thanks for that.
so that will be the next great question:
How can we send  _politically correct_ ;-) PullRequests to FreeBSD?


----------



## Jose (Jan 1, 2021)

ucomp said:


> Olè guys and happy new year !


Is this some kind of ethnic joke? BTW the grave accent is not a thing in Spanish. The correct way to spell that word is olé. Also, I'm from Latin America, and we don't use it very often.


ucomp said:


> ...while good point what you say, there's no problem for me  with, because I fork the mirror again to a place where I can do every possible chaos of code  without breaking something...that's the comfortable thing with those "HUBs", you can do a lot with some clicks as long as you know what you're doing.
> 
> I was amazed that no one has gone into it so far, so thanks for that.
> so that will be the next great question:
> How can we send  _politically correct_ ;-) PullRequests to FreeBSD?


Just so you know, Google translate is making you sound completely insane.


----------



## ucomp (Jan 1, 2021)

Jose said:


> Is this some kind of ethnic joke? BTW the grave accent is not a thing in Spanish. The correct way to spell that word is olé. Also, I'm from Latin America, and we don't use it very often.


No, I didn't even think of anything ethnic. As a football fan, I use this word when players of my favourite team push the ball to one another.  

so let me please try my Spanish WITHOUT google translate, although it's a long time ago when I was very often in Latin America :

`porque esto es la verdad que google translate no siempre hables la verdad ,
yo olvido mucho la idioma español pero yo recuerdo bueno tu bien país`. 

wow, `have put it in the translator and doesn't work quite good ...


----------



## msplsh (Jan 1, 2021)

ucomp said:


> How can we send _politically correct_ ;-) PullRequests to FreeBSD?


Phabricator


----------



## ucomp (Jan 1, 2021)

msplsh said:


> Phabricator


of course, as state of today phab is used. but will FreeBSD accept PRs from e.g. public GitHub/GitLab in the near future and will those collaboration platforms be accepted as a replacement for phab-reviews, issue-reports etc.?


----------



## jb_fvwm2 (Jan 1, 2021)

`git clone -b stable/12 --depth 1 https://git.freebsd.org/src.git src` works
as svn did for a non-existant yet /usr/src... unsure if it has been
posted yet in this thread, but probably also should be somewhere in /usr/src/UPDATING as well as an equivalent for /usr/ports/UPDATING when
that also switches.
.............
corrections welcome.
.............
Information came from one of the mailing lists just very recently.


----------



## msplsh (Jan 1, 2021)

ucomp said:


> will FreeBSD accept PRs from e.g. public GitHub/GitLab in the near future and will those collaboration platforms be accepted as a replacement for phab-reviews, issue-reports etc.?


That's a request for a "forward looking statement" and none has been made.

I don't see why this would change from the current status of "no" and "no" given that it would bifurcate things.


----------



## ucomp (Jan 2, 2021)

msplsh said:


> That's a request for a "forward looking statement" and none has been made.


perhaps I'll try it out. in the past(or currently) we would clearly redirected to phabricator.


msplsh said:


> I don't see why this would change from the current status of "no" and "no" given that it would bifurcate things.


I _do _see why this would change from the current status of `no`:  why not  use the whole git-ecosystem? wouldn`t it expand instead of bifurcate? or perhaps a trick like _automatically_ forward git-PRs to phab and/or vice versa? well, we'll see


----------



## tingo (Jan 2, 2021)

Since nobody has suggested it in this thread yet; one reason for having repository mirrors at github / gitlab can be for larger exposure; since a lot of people already are on Github / Gitlab, having the FreeBSD source code there increases the chance that users will discover it there. It also might lower the "feedback barrier" for casual users; users on Github / Gitlab probably already know how to open an issue.


----------



## scottro (Jan 2, 2021)

And for CURRENT `git clone https;//git.freebsd.org/src.git` works.  (I didn't use --depth 1 but probably should have. Thanks jb_fvwm2, in all the digressions in this thread, I also thought of posting the actual commands, but you were first to do so.[/cmd]


----------



## Jose (Jan 2, 2021)

ucomp said:


> ...(W)hy not  use the whole git-ecosystem? wouldn`t it expand instead of bifurcate?


Github pull requests are not the same as Git pull requests. Read Linus on the subject:








						Add support for AR5BBU22 [0489:e03c] by reejk · Pull Request #17 · torvalds/linux
					






					github.com
				




The Freebsd project should not become vendor-locked to a single commercial entity that can decide to change the free hosting agreement at any time. That would be unwise.

How would it expand without bifurcating?


ucomp said:


> or perhaps a trick like _automatically_ forward git-PRs to phab and/or vice versa? well, we'll see


What problems with the current Phabricator flow are solved by adopting the Github system? Who's going to write and maintain the compatibility forwarder you describe?


----------



## ucomp (Jan 2, 2021)

Jose said:


> Github pull requests are not the same as Git pull requests. Read Linus on the subject:
> 
> 
> 
> ...


....  torvalds commented on 11 May *2012* : ......
Maybe some of this has changed, I haven't checked lately......
---
did you check lately?



Jose said:


> Who's going to ... ... *maintain* ....?


_*There can only be one*_
SirDice of course, who else?


----------



## msplsh (Jan 2, 2021)

ucomp said:


> I haven't checked lately......
> 
> did you check lately?


Why type this sentence and not look yourself at the PR list?  Jose's sentence after the link outlined why even if it were not true anymore why it wouldn't matter (probably why it doesn't matter for linux either, if you spend five seconds to find and read the bot's boilerplate).


----------



## ucomp (Jan 2, 2021)

msplsh said:


> Why type this sentence and not look yourself at the PR list?....* spend five seconds*...


because it's an open secret that Linux doesn't accept GitHub-PRs.  I would have been more interested in whether this technical barrier actually still exists (because I don`t know and I haven`t checked lately, like torvalds ).
And even if the problem is big, that doesn't necessarily mean that someone doesn't want to take a different route to accept PRs on collaboration platforms. Of course, I don't care personally, I can also use phabricator, where I have *spent* some of my *five seconds* today  . But to make PRs "more open" would be nice.


----------



## msplsh (Jan 2, 2021)

If you don't care personally, what is all this talk about Github even for?  Do you have a point you'd like to make that hasn't already been addressed?


----------



## zirias@ (Jan 2, 2021)

Because accepting a PR on Github is a huge PITA unless you have your "central" repository hosted there?

This thread is out of control. It now really makes me wonder why ppl can't STFU if there's nothing on topic to write…


----------



## scottro (Jan 5, 2021)

Having looked at the Losh article and others, (and looked at https://cgit.freebsd.org/src/) I understand how I would use git clone to get 12.2 source. But -b stable/12 only gets me 12.2  What command would I use to get 12.1? The equivalent of svn co https://<server>/bash/releng/12.1?
Even looking at the cgit browser, I don't see it, probably my lack of knowledge, but with an svn browser, I can see base/releng/12.1.


----------



## msplsh (Jan 5, 2021)

I clicked the [...] under branches to load all of them and was greeted with https://cgit.freebsd.org/src/log/?h=releng/12.1


----------



## a6h (Jan 5, 2021)

scottro said:


> I understand how I would use git clone to get 12.2 source. But -b stable/12 only gets me 12.2  What command would I use to get 12.1? The equivalent of svn co https://<server>/bash/releng/12.1?


`git clone -o freebsd -b stable/12 --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' https://git.freebsd.org/src.git freebsd-src-stable-12`


----------



## Jose (Jan 5, 2021)

`git clone -b releng/12.1 --depth 1 https://git.freebsd.org/src.git`
Works. It might make sense to clone the whole tree if you're going to work on multiple branches. Then all you have to do is

```
git checkout --track origin/releng/12.1                                                                 
Updating files: 100% (54334/54334), done.
Branch 'releng/12.1' set up to track remote branch 'releng/12.1' from 'origin'.
Switched to a new branch 'releng/12.1'
```


----------



## zirias@ (Jan 5, 2021)

Is disk space really a thing nowadays? I worked with GIT for a long time, and normally, I work on a FULL clone, including ALL branches. It's just very convenient. Seriously, FreeBSD isn't THAT huge…


----------



## a6h (Jan 5, 2021)

Zirias said:


> Is disk space really a thing nowadays? I worked with GIT for a long time, and normally, I work on a FULL clone, including ALL branches. It's just very convenient. Seriously, FreeBSD isn't THAT huge…


Not really. If bandwidth or internet plan is not an issue, I think cloning the whole tree is the easiest approach.


----------



## chrcol (Jan 11, 2021)

this look good to you guys?  (preserving custom kernel files doing pull).


```
if [ ! -d $srcpath ]; then
        #shallow clone
        git clone $url -b $version --depth 1 $srcpath
        #deep clone
        #git clone $url -b $version --single-branch $srcpath
else
        cd $srcpath
        git stash
        git pull --ff-only
        git stash apply
        cd $curpath
fi
```


----------



## chrcol (Jan 11, 2021)

Zirias said:


> Is disk space really a thing nowadays? I worked with GIT for a long time, and normally, I work on a FULL clone, including ALL branches. It's just very convenient. Seriously, FreeBSD isn't THAT huge…



Had a giggle, yes it is.  I giggled as I hear it from so many developers 

I am not working on the source code, for me my only interest is to download the code I need to compile it.


----------



## Jose (Jan 14, 2021)

chrcol said:


> ```
> git stash
> git stash apply
> ```


Why not keep the custom kernel files in a branch? Looks like `git stash apply` will keep all your previous stashes. Won't that get confusing after a while? Also keeping your kernel configs in a branch will let you diff arbitrary versions, etc.


----------



## zirias@ (Jan 15, 2021)

Jose said:


> Why not keep the custom kernel files in a branch? Looks like `git stash apply` will keep all your previous stashes. Won't that get confusing after a while? Also keeping your kernel configs in a branch will let you diff arbitrary versions, etc.


Additionally, with a local branch, you might want to have a look at `git rebase`. Embrace local branches, one of the advantages you'll have now


----------



## ralphbsz (Jan 15, 2021)

No, it does not. Git itself is free software, you can download it anywhere and read the source code, which is NOT owned by microsoft. To use git in practice, you need some sort of git server. The main server for FreeBSD's code repository is owned and controlled by the FreeBSD project.

What is true: there is a large git server called "github", which has copies of many software project. Including one copy of the FreeBSD source code. And that server is owned by Microsoft. But you can do git perfectly well without using github.

The more important question is not the technical details. It is: why are you even asking this question? Are you afraid of Microsoft? Microsoft is one of the larger supporters of free and open software, so what would be wrong with using Microsoft servers for source code?


----------



## msplsh (Jan 15, 2021)

Github is Microsoft, that is true, HOWEVER, if you managed to learn _that_ *but* *not* the following, please practice:

Git is not Github.
Git does not depend on Github. (The converse is true, however)
Git is a system that can be implemented by BSD licensed software.


----------



## msplsh (Jan 16, 2021)

This question is worded a bit strangely, so:

* The FreeBSD source repository will be stored in git, which is a type of storage format as well as the name of a piece of software
* Github stores git repositories.
* FreeBSD has a copy of their repository on Github.
* The master copy of the FreeBSD repository is not on Github.


----------



## ralphbsz (Jan 17, 2021)

msplsh said:


> * Github stores git repositories.


True. But git repositories can also be stored many other places. I think I have at least half a dozen at home for my personal software, and they are only stored on my home server, and nowhere else (in particular not on GitHub). Matter-of-fact, because of git's distributed nature, there is typically not one "server" repository and many "clients", but repositories are equivalent. Anyone who downloads the complete source will have a repository on their own computer. And in theory could re-distribute their own repository to other people, and start a whole separate tree. However, there is typically or a few repositories from which official builds are made.



> * FreeBSD has a copy of their repository on Github.


True. But it is only one of many copies. I could make a copy of the source (honestly, I've rarely downloaded the FreeBSD source in my life), and modify it to my heart's content, and redistribute it, if I felt like it.



> * The master copy of the FreeBSD repository is not on Github.


That's the copy from which the official builds are made, and which the official developers work on.


----------



## msplsh (Jan 17, 2021)

Had reason to try this

`pkg install git-tiny`
(installs 0 dependencies on my system)
`git clone -o freebsd -b releng/12.2 --depth 1 https://git.freebsd.org/src.git /usr/src`

Well, that was easy...


----------



## chrcol (Jan 23, 2021)

Jose said:


> Why not keep the custom kernel files in a branch? Looks like `git stash apply` will keep all your previous stashes. Won't that get confusing after a while? Also keeping your kernel configs in a branch will let you diff arbitrary versions, etc.


I have no idea on git syntax, I always felt svn is way more user friendly thats why I asked on here.    Thanks


----------



## ralphbsz (Jan 23, 2021)

Look on the web for a SVN to git translation table. I'm sure they exist. When I started using Mercurial (both at work and at home), I printed a translation table of git -> hg commands and taped it on the edge of my monitor at work.


----------



## jb_fvwm2 (Jan 23, 2021)

Not really on topic, but 13-STABLE has been branched.


----------



## scottro (Jan 23, 2021)

Thanks, been running a laptop that right now requires CURRENT for video to work right. This means upgrading pkgs often messes things up.  Looks like it (13.x) is almost on schedule, I'll probably wait till an RC is released to change the laptop though.


----------



## T-Daemon (Jan 24, 2021)

scottro said:


> ... been running a laptop that right now requires CURRENT... Looks like it (13.x) is almost on schedule...



I hope this is not seen as nit-picking addressing this minor detail (I have been recently accused doing so by focusing on such), CURRENT (git main) is now 14, after stable/13 has been branched.



scottro said:


> This means upgrading pkgs often messes things up.


Since stable/13 has been branched on 01/22/2021 a new drm-kmod port (package), graphics/drm-fbsd13-kmod, has been introduced, upgrading might go more smoothly.



scottro said:


> I'll probably wait till an RC is released to change the laptop though.


Meanwhile, maybe you are interested, there is an FreeBSD-13.0-ALPHA2 image availaible, freebsd-update(8) should be working.


----------



## scottro (Jan 24, 2021)

Thanks for the updates. I may try that, and no, it's not nitpicking, it's giving the correct information.  I guess I should, if getting into this, start another thread, as I'm taking it way off topic, but I do thank you for the information.
But on topic, seems I can get that source with

`git clone -b stable/13` , etc.
Doing that, and running
`egrep "^REVISION|^BRANCH" newvers.sh`
gets me

```
REVISION="13.0"
BRANCH="ALPHA2"
```
(but freebsd-update isn't working with it yet)


----------



## Jose (Jan 25, 2021)

chrcol said:


> I have no idea on git syntax, I always felt svn is way more user friendly thats why I asked on here.    Thanks


I have a love-hate relationship with the Git stash. It can be awfully handy, but it can also cause confusion if you abuse it. Typically something like this happens. I'm working along, and I need to pull in some changes that someone else has committed. Let's look at a contrived example using the Freebsd source:

```
$ git status
On branch releng/12.1
Your branch is up to date with 'origin/releng/12.1'.

nothing to commit, working tree clean
$ vi README
$ git pull
error: cannot pull with rebase: You have unstaged changes.
error: please commit or stash them.
```
Arrgh, I have some changes I'm not ready to commit, but I really, really need to rebase to upstream. I know, I'll stash them

```
$ git stash
Saved working directory and index state WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.
$ git stash list
stash@{0}: WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.
$ git pull
remote: Enumerating objects: 5277, done.
remote: Counting objects: 100% (5277/5277), done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 12398 (delta 5230), reused 5194 (delta 5191), pack-reused 7121
Receiving objects: 100% (12398/12398), 9.88 MiB | 12.83 MiB/s, done.
Resolving deltas: 100% (8989/8989), completed with 3679 local objects.
From https://git.freebsd.org/src
   fb6bc290fb3..94ac312a716  main                                                  -> origin/main
...
$ git stash pop
On branch releng/12.1
Your branch is up to date with 'origin/releng/12.1'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   README

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (e6a9cef2a2a028c06ac996b885f6168c54110ced)
$ git stash list
```
So far so good. You might notice I used "pop" instead of "apply". The pop applies the most recent change, and then drops it. My stash is empty afterwards. The stash is a last-in, first-out stack of changes. Let's say I stash multiple times.

```
$ git status
On branch releng/12.1
Your branch is up to date with 'origin/releng/12.1'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   README

no changes added to commit (use "git add" and/or "git commit -a")
$ git stash list
stash@{0}: WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.
stash@{1}: WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.
```
I've made three conflicting changes to README for this contrived example. The change in the working tree (notice README is marked as "modified") will conflict with the last change I pushed on to the stash. Let's see what happens when I try to pop it.

```
$ git stash pop
error: Your local changes to the following files would be overwritten by merge:
    README
Please commit your changes or stash them before you merge.
Aborting
The stash entry is kept in case you need it again.
$ git stash list                                                                              
stash@{0}: WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.
stash@{1}: WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.
```
Now what? I have to `git stash show -p`

```
$ git stash show -p                                                                           
diff --git a/README b/README
index aad363baf9e..7aa1dfb46c7 100644
--- a/README
+++ b/README
@@ -78,3 +78,4 @@ For information on synchronizing your source tree with one or more of
the FreeBSD Project's development branches, please see:

   https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html
+bar
diff --git a/README.md b/README.md
index 72bd634cd81..939b885a59c 100644
--- a/README.md
+++ b/README.md
@@ -80,3 +80,4 @@ For information on synchronizing your source tree with one or more of
the FreeBSD Project's development branches, please see:

   https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html
+foo
```
Notice this shows the newest change first (again the stash is a LIFO). This is not too bad because this is a shallow stack with trivial changes. Imagine if you had dozens of stashes with non-trivial changes in them. That's the situation you're setting yourself up for because `git stash apply` does not drop stash entries after it applies them like `git stash pop` does.

I'm re-reading this and I'm not sure I'm being clear. Questions and comments welcome.


----------



## olli@ (Jan 25, 2021)

ralphbsz said:


> Look on the web for a SVN to git translation table.


It’s not that easy. Subversion and Git have quite different paradigms, so you cannot translate all commands one-to-one.

For example, with Subversion you can check out a source tree from a server (e.g. from FreeBSD’s public subversion repository). You cannot do that with Git, because Git doesn’t work that way. Instead, you have to clone a repository (or a branch) to your local machine. As a result, you have a clone of the repository, plus a working tree. (Beware, Subversion’s term “checkout” has a different meaning with Git.)


----------

