- Registrado
- 7 de Abr, 2025
Well that's what I need it for right now, but I'm gonna have to ... actually use it for whatever it's used for in the future. Which I'm not sure what that is lol
Programming thread
- Iniciador del tema Splendid
- Fecha de inicio
-
🔧 Site instability resolved. You can report double-posts and broken attachments. For bigger issues, use the Technical Grievances thread.
🇵🇦 Nuestro primer dominio localizado está en español en kiwifarms.pa. Our first localized domain is on Spanish on kiwifarms.pa. -
Want to keep track of this thread?
Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
Create account
August Levasseur
kiwifarms.net
- Registrado
- 13 de Dic, 2022
The upload to website option only exists if you own/have control of the repo (I think?). The way to do this properly is to make a folder, go to the command line, do a ‘git clone <repo_url>’ if your friend already has a repo, or do a ‘git init’ if he doesn’t. If he doesn’t have a repo, go to github and create one, then do a ‘git remote add origin <repo_url>’. Then copy in whatever file(s) you have to the directory where you did the git init. Then you do a ‘git add <file_name>’ for all of your files, then do a ‘git commit -m “<message>”’ do commit the changes to the git tree, then do a ‘git push’ to push the changes to the git repo. You’ll get a prompt to login to the repo, github has some faggot ass bullshit where you can’t just use your username and password, you have to create a special key and then copy that in everytime you do a commit. It’s annoying.
In the future, whenever you change files or add them to the repo, you go through the same cycle. ‘git add <file_name>’ for new files or ‘git add -u’ to add changes to a commit, commit the changes to git with ‘git commit -m “<message>”’ and push the commit to the repo with ‘git push’. If your friends are also pushing changes, you’ll want to sync your local git to the repo regularly with ‘git pull’.
In the future, whenever you change files or add them to the repo, you go through the same cycle. ‘git add <file_name>’ for new files or ‘git add -u’ to add changes to a commit, commit the changes to git with ‘git commit -m “<message>”’ and push the commit to the repo with ‘git push’. If your friends are also pushing changes, you’ll want to sync your local git to the repo regularly with ‘git pull’.
- Registrado
- 15 de Jun, 2017
Git is a version control system. It's like keeping copies of a file that you work on except better organized; also, git is particularly good for text files (pure text, such as Notepad and code -- not Microsoft Word) because it's very good at showing differences between versions and performing operations on these differences (copying, deleting, combining multiple versions into one, etc). Only one version exists at the same time on disk as original browsable/editable files, everything else is stored in the history in complicated ways. You can pick and activate any version at any time.
But, what if several people are working on the same project and they need to update each other on their work? You can put your whole work history into a zip file and send it to someone else, but then he'd have to somehow add your changes to his own. With many people working on their own tasks (or perhaps on the same task!) at the same time, this gets impossible. What people do is make a git server, and then each participant updates the server ("push") and downloads other people's updates ("pull"). You can set your own server on a computer you own or rent. There is/was a KiwiFarms git server.
Because git is free, there are multiple businesses that
- offer to host a server and add their own proprietary gay features such as comments on code, comments on versions, dashboards, discussions, complaints, etc
- and/or make proprietary software that's a git server with their proprietary gay features for you to host.
Github does both: there's github.com, the social network for trannies and jeets where they sometimes post code, and Github Enterprise Server (to run your own social network).
VSCode/VSCodium has a github addon that integrates with their faggot ass bullshit and allows logging in on the website, somehow.
@Wigger Rights Advocate, VSCode (Microsoft pozzed), VSCodium (de-Microsofted) and other text/code editors for bad programmers have a graphical interface for git and Github.
glossary:
- commit (noun): a saved and numbered version, a.k.a. "revision"
- commit hash / revision number: a 40-digit hexadecimal number of the commit
- commit (noun) message: the human-readable name of the version that you write yourself
- commit (verb): save a snapshot of the selected changes as a new version
- stage (verb): add changes to be saved in the next commit (you don't have to save all changes at once)
- branch: a series of commits, commits can only be added to the end of a branch
- check out (verb): restore a version to disk
- head: the commit that's currently checked out
- detached head: what happens when you check out a specific version by its 40-character number rather than a branch (you won't be able to commit your changes)
- a commit that's not on the end a branch will always be a detached head, a commit that's on the end of a branch can also be unintentionally checked out as a detached head
- unsaved changes: changes that are not formally saved to the file on disk (your text editor might still keep them somewhere, just in case) -- if you open the file with a different editor, these changes will not be visible
- uncommitted changes: differences between files on disk and the end of the currently active branch; when you check out another commit, you will lose uncommitted changes
- stash (noun, verb): git's special cache to optionally store uncommitted changes when you just want to have a brief look at another commit and come back to your work
- editors can have their own stashes
- unstaged changes: differences between files on disk and the end of the currently active branch that haven't been added and therefore won't be included in the next commit
- origin: the default name for the remote server; git can keep some "origin" branches cached locally
- push: upload your commits to a remote server and add your changes
- force push: upload your commits to a remote server and overwrite someone else's changes with yours
- merge: what you do if you want to push your changes to the server but someone else added other changes and you don't want to lose them
- pull: download someone else's commits from the server and merge them with your work
- fetch: download someone else's commits from the server but only update the local cache of remote branches, do not merge with your work
- merge conflict: git can't decide how to merge two versions and makes specially annotated files for you to fix manually
Última edición:
- Registrado
- 7 de Abr, 2025
Okayy, I'm using vscode and didn't know about that ! Thank you for the help kiwis
- Registrado
- 4 de Nov, 2024
Ad VCSs, has anyone here tried fossil? Recently, I've set it up for one of my projects and so far I really like it. The commands are simple and intuitive, and the built-in web UI is pretty cool. I think it may replace git for me.
I also really like the way those "repository files" work. Super easily portable and you can have multiple different branches checked out from the same repo with basically no setup on a local machine.
I also really like the way those "repository files" work. Super easily portable and you can have multiple different branches checked out from the same repo with basically no setup on a local machine.
Última edición:
- Registrado
- 1 de Ene, 2021
If "junior" means someone who learned COBOL years ago and is still breathing, then maybe.
I'm almost tempted to apply myself, but Poland.
- Registrado
- 23 de Sep, 2018
I mentioned it briefly a few days ago. In short, I really like the concept of having all the standard VCS periphery tools (issues, wikis, etc.) built into the tool itself, but after two decades of using Git I'm just too used to how Git works for me to stick with it every time I consider changing, and that's even before considering the massive network effect of GitHub.
Maybe some day I'll want/need to work on a project which only uses Fossil and I'll have to learn it that way (just like what happened when I switched from CVS to Git), but unfortunately that seems unlikely in the near future.
So instead I stick with Git, and have to choose between GitHub and Codeberg, a company who thinks humans shouldn't write code anymore and a company still doing performative leftist politics like it's 2015.
- Registrado
- 1 de Abr, 2024
I've been watching this channel for a bit. Generally I enjoy his stuff. It's almost always some nerdy video diving into something involving programming. A lot of the time it's c. He had one where he looked into bc i believe (it might be the other calculator, i forget the name of) after seeing it was a dependency to compile the linux kernel, and dove into what it does, and how the calculator basically has it's own programming language.
I thought I would share a video from him here in case people haven't seen his channel. I'm not sure where he's from, my guess is Russia based on the accent, but idk.
- Registrado
- 4 de Mar, 2023
hes from novosybirsk
tsoding is the reason i got back into programming. seeing videos saying "drill DSA learn javascript" etc really drove me away from programming (didnt help that i was stuck in tutorial hell)
then i stumbled into a vod of his, i saw him use non-retarded language without any libraries, if anything just used example code and documentation, and it really motivated me to get back, showed me that no, modern day programming hasnt yet devolved into strictly just gluing javascript libraries together
i really recommend this guy
- Registrado
- 15 de Jun, 2017
Just took a look at it. Multiple checkouts per repo are nice, but §§ 2.7 and 2.8 make it a nonstarter, bordering on spyware / thot control / wagie cagie in a corporate environment. Those people are weird.
I commit when I want an intermediate result saved. I don't test them, I don't even lint them (too slow). When I think I'm done, THEN I lint and test, squash with a nice message and push. I do not want to abstain from saving my work so as to not make shitty intermediate results ("sneed", "mm", "DO NOT PUSH", "wip" "eh, "meh", "ser", "almost done", "done?", "nigger", "wut", "typo", "i hope it works now", etc) a matter of permanent public record.
Why is it a problem if I save my work notes to the local repo?
Nah, fossil is "what I was doing" and git is "what I got done".
August Levasseur
kiwifarms.net
- Registrado
- 13 de Dic, 2022
Mista A Zozin is cool. I like him, but I disagree with some of his takes. In particular, I think that little languages and external utilities are heccin valid and deserve to exist. Most build system suck, but that doesn’t mean the concept of a build system is bad. mk is pretty good, and even plain old make isn’t that bad if you know how to use it.
Generally, his stuff is based and codepilled, thoughever.
- Registrado
- 23 de Sep, 2018
Coming from the CVS and Subversion days, we didn't work that way. The general idea was that you never intentionally committed code in an incomplete state; a user should be able to clone any branch at any time and have a functioning code base, even if it's incomplete. I still commit with that attitude personally, even on repos which will never be touched by anyone but myself. Fossil came about before the Git concept of "go ahead and shitcommit in a private branch and then rewrite history to make it look prettier before merging" was really a concept that crossed anyone's mind as being desirable, in their defense.
- Registrado
- 21 de Nov, 2020
I commit early and often so that if my device I'm working on goes "poof" then all my work is saved. Also I often work with tools that only connect to the repo to run the code, so I have to commit to even get the code tested.
ChompChomp
kiwifarms.net
- Registrado
- 2 de Feb, 2025
Why couldn't you just use tags to indicate the latest working state of a branch or repo?
Otherwise, even if a branch compiled fine, qnyo clonin a branc your working on with a ton of uncommitted changes is going to have an amazing time resolving conflicts and redoing their own code to align with all the new junk you threw their way.
The only "working" (i.e., compiling) branch needs to be whichever one is configured for that purpose.
I'd rather see chunky WIP vs nothing.
- Registrado
- 10 de Sep, 2021
Build systems, and especially the nightmares that are Cmake, Gradle, and Maven, leave a lot of room for discussion. The best build systems are things like
odin build src or love ..August Levasseur
kiwifarms.net
- Registrado
- 13 de Dic, 2022
I dunno. The thing I like least about Go is its build system, which is one of those ‘go build .’ kinda thing. Imo, it works well if your project is within the range of things that Go expects, but if you’re trying to do something unusual it gets to be like debugging through a keyhole. Whenever I use mk I use a set of template build scripts, so if I’m doing something normal it’s as simple as listing the files and libraries in the mkfile, but if I want to do something unusual, like run a code generator or do some post-processing on the binaries, I can just edit the templates to add whatever step I need in the right spot.
I suspect Go is on the far end of whatever spectrum exists with build systems, where most languages wouldn’t make it so hard to contrort the process how you need it.
- Registrado
- 10 de Sep, 2021
Love especially has post processing requirements, but any kind of pre or post processing necessary for the build I'm far more comfortable doing from a shell script over the utterly bizarre and arcane systems of Cmake.
- Registrado
- 4 de Mar, 2023
August Levasseur
kiwifarms.net
- Registrado
- 13 de Dic, 2022
U should learn the one that brings you the most happiness
And then also C bc at some point you’ll want to make somethung useful.
I like Go bc I think they paid incredibly close attention to the ergonomics of the language so it feels really nice to write things in it (endless if err != nil -s notwithstanding). Plus there’s lots of great documentation and tutorials out there. Two I like are A Tour Of Go, which the devs themselves put out, and Go By Example, which is just a demonstration of all the different features of Go with little examples.
Última edición: