421–430 of 454 posts
Earlier quoted context omitted.
I read an article not long ago where students coming out of a web dev bootcamp were unable to make a hello world html file and open it in their browser. We’ve gone so far with elaborate environments and sets to make it easy to learn more advanced things, that many people never learn the very basics. I see this as a real problem.
With cors this can be awkward now.
Earlier quoted context omitted.
That's not accurate. I've had one of my own accounts blocked, with zero access until I talked to their support and convinced them I was, in fact, a real person. At that moment, if I had any important private repos, they would be gone.
That's no reason not to use them as a third offsite backup on top of your laptop and your own server hosting, which is what I'm suggesting here.
Earlier quoted context omitted.
I'm assuming a "patch" is a group of commits. So would a "patch series" be similar to GitLabs notion of dependent MRs?
There's basically 2 major schools of thought for submitting patches under git: * Pile of commits - each individual commit doesn't matter as much as they all work combined. As a general rule, the only requirement for a valid patch is that the final version does what you say it does. Either the final result is squashed together entirely and then merged onto "master" (or whatever branch you've set up to be the "stable"…
The second one makes sense, but I can't imagine actually working that way on any of the projects I've been in. The amount of work it would take just doesn't make sense. Can totally understand why it would be useful on something like the Linux Kernel though.
So my friend and I were trying to learn some coding together. We had our laptops on the same wifi and I wanted us to use git without depending on GitHub, but I was completely stumped as to how to actually connect us together. I don't want us to setup SSH servers on each other's laptops, giving each other full access to our computers, and sending patches to each other across the living room seems overkill when we're j…
Another option would be to use the email-based workflow, but that's quite different from most people's expected git experience.
In interviews, I've literally asked senior devops engineers and senior software engineers if they have hosted their own git servers and how to initialise one and not a single one has mentioned git init --bare..... which is disconcerting. They can deploy appliances (like gitlab, gitea) and build pipelines just fine, but none of them realized how git actually works underneath and how simple it all is.
Why is that disconcerting? There's simply too much software to be familiar with obscure features like this
Same issues with git: they don't realise they can have multiple configs, multiple remotes, etc. Never mind knowing how to sign commits.........
They claim to be linux boffins but cannot initialise a git repo. This has nothing to do with elitism. This is basic stuff.
What's next, they don't know what a bootloader or a partition is? Or run database engine with default settings? Or install a server OS and never bother to look at firewall config?
I'm truly not trying to be cruel.
My favorite git trick is using etckeeper & git subtree to manage multiple machines from a single repo . A single git repo can “fan out” to dozens of instances . It’s useful even for “managed” hosts with terraform because etckeeper snapshots config with every change, catching bugs in the terraform config. During the dev / compile / test flow, git makes a lightweight CI that reduces the exposure to your primary repo .…
Care to share a little bit more about this? I've been thinking of using git with `--work-tree=/` to track system files, so I'm interested in these "unusual" setups with git. Not sure I got the "fan out" concept here.
On your primary repo, create dirs for each machine e.g.
monorepo/
├─ Machine1/
│ ├─ usr/share/www/
│ ├─ etc/
├─ machine2/
│ ├─ etc/
Then add the subtree with `git subtree add -P machine1/etc hosts/machine1/etc master`
When you want to pull changes you can `git subtree pull` or `git subtree push …`
If you end up making changes in your monorepo, use push. If you make changes directly on the machine (or via terraform), pull
This way you can edit and manage dozens of machines using a single git repo, and git subtree push to deploy the changes. No deploy scripts.
My favorite git trick is using etckeeper & git subtree to manage multiple machines from a single repo . A single git repo can “fan out” to dozens of instances . It’s useful even for “managed” hosts with terraform because etckeeper snapshots config with every change, catching bugs in the terraform config. During the dev / compile / test flow, git makes a lightweight CI that reduces the exposure to your primary repo .…
Care to share a little bit more about this? I've been thinking of using git with `--work-tree=/` to track system files, so I'm interested in these "unusual" setups with git. Not sure I got the "fan out" concept here.
I feel like something was lost along the way. git init —-bare will give you a git repo without a working set (just the contents typically in the .git directory). This allows you to create things like `foo.git` instead of `foo/.git`. “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like. You can even namespace where you push back to th…
> “origin” is also just the default name for the cloned remote I don't have a central dotfiles repo anymore (that I would always to forget to push to); I have SSH access to my devices - via tailscale - anyway so I'm doing git remote add $hostname $hostname:.config and can cd ~/.config && git fetch/pull/rebase $hostname anytime from anywhere. I've been considering a bare repo + setting $GITDIR (e.g via direnv) but som…
I put my whole home folder in git and that has its benefits (being able to see changes to files as they happen) but if I'm just copying a file or two of config I'll just cat or scp it--introducing git seems needlessly complex if the branches are divergent
Earlier quoted context omitted.
> all the experts you know use it in slightly different ways What? Knowing that a git repo is just a folder is nowhere near "expert" level. That's basic knowledge, just like knowing that the commits are nodes of a DAG. Sadly, most git users have no idea how the tool works. It's a strange situation, it'd be like if a majority of drivers didn't know how to change gears.
> just like knowing that the commits are nodes of a DAG Hello gatekeeping! I have used Git for more than 10 years. I could not explain all of the ins-and-outs of commits, especially that they are "nodes of a DAG". I do just fine, and Git is wonderful to me. Another related example: I would say that 90%+ of .NET and Java users don't intimately understand their virtual machine that runs their code. Hot take: That is fi…