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
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.
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?
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.
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.
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.
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?
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 originto 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 ;-)
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.
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."
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.
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.
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.
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) .
---
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...)
.....
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."
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.
Push and pull are standard Git functionality. They have absolutely nothing to do with Github.
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...
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.
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 ;-)
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.
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.
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".
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.
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.
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".
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 .
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.
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?
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.
...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?
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.
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.?
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.
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.?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
:
