341–350 of 454 posts
Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?
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.
Earlier quoted context omitted.
> I imagine there's a way to setup a hook on your own server such that any pushes are then pushed to a GitHub copy without you having to do anything else yourself. For most people, that would defeat the purpose of self-hosting.
If your purpose for self-hosting is fear that GitHub will ignore their own promises in their terms of service and abuse their custody of your data then sure. https://docs.github.com/en/site-policy/github-terms/github-t... (There's also the "to comply with our legal obligations" bit, which is a concern if you're doing things that governments around the world may have issue with.) I expect there are people who like to…
At that moment, if I had any important private repos, they would be gone.
I suspect many who always use git remotely don't know that you can easily work with local repositories as well using the file protocol, git clone file:///path/to/repository will create a clone of the repository at the path. I used that all the time when I had to move private repositories back and forth from work, without ssh access.
For file protocol, just type a path.
For ssh, type a ssh connection string like lion@myserver.test:path/to/file
Earlier quoted context omitted.
Same as always, with any other remote? (Use `git pull`? If the different people push to different branches, then there's no conflict and no problem. If you try to push different things into the same branch, the second person will get told their branch is out of date. They can either rebase or - if this is allowed by the repo config - force push over the previous changes...)
Sure, if they push one after the other. If they push at the same time however, does Git handle the sync on its own?
- a prod server ( and a test server) with a git repo.
- a local machine with the git repo.
- a git server where code officially lives, nowadays just a github.
If I were to simplify and run my own git server of the third kind, I would probably not run a server for the sole purpose of hosting code, it would most likely run on the prod/test server.
So essentially I would be eliminating one node and simplifying. I don't know, maybe there's merits to having an official place for code to be in. Even if just semantics.
I know you can also use branches to have a "master" branch with code and then have migrations just be merging from master into a prod branch, but then again, I could have just master branches, but if it's on the test server then it's the test branch.
I don't know if spendint time reinventing git workflows is a very efficient use of brain juice though.
mkdir -p repo/project
cd repo/project
git init --bare
cd ../..
git clone repo/project
cd project
(do git stuff)Earlier quoted context omitted.
My way used to be in the past, put bare repos on Dropbox, clone the bare repo to a real path. Done. That way, I 1. didn't have to worry about sync conflicts. Once complete, just push to origin 2. had my code backed up outside my computer I can't exactly remember, if it saves space. I assumed it does, but not sure anymore. But I feel it was quite reliable. I gave that way up with GitHub. But thinking of migrating to `…
That doesn't work -- I've tried it. I mean, it works fine for a few days or weeks, but then it gets corrupted. Doesn't matter if you use Dropbox, Google Drive, OneDrive, whatever. It's apparently something to do with the many hundreds of file operations git does in a basic operation, and somehow none of the sync implementations can quite handle it all 100.0000% correctly. I'm personally mystified as to why not, but c…
Earlier quoted context omitted.
That doesn't work -- I've tried it. I mean, it works fine for a few days or weeks, but then it gets corrupted. Doesn't matter if you use Dropbox, Google Drive, OneDrive, whatever. It's apparently something to do with the many hundreds of file operations git does in a basic operation, and somehow none of the sync implementations can quite handle it all 100.0000% correctly. I'm personally mystified as to why not, but c…
With bare repos? I was bit by this a few years ago when work switched to "everything on OneDrive" and it seemed fine until one day it wasn't. Following that I did tests with Dropbox and iCloud to find that all could corrupt a regular repo very easily. In the past few months though I've been trying it again with bare repos on iCloud and not had an issue... yet.
Good luck with iCloud!
Earlier quoted context omitted.
This sort of thing is part of the problem. If it takes reading such a long manual to understand how to properly use Git, it's no wonder everyone's workflow is different.
I don't see it as a problem that everyone's workflow is different, and, separately, I don't see it as a problem that it takes reading such a long manual to understand all the possibilities of Git. There is no royal road to geometry. Pro Git is a lot shorter than the textbook I learned calculus from. Unlike calculus, though, you can learn enough about Git to use it usefully in ten minutes. Maybe this sets people up fo…
Earlier quoted context omitted.
It still blows my mind how git has lost it's original ideas of decentralized development because of github and how github, a for-profit - centralized - close-sourced forge, became the center for lots of important open source projects. We need radicle, forgejo, gitea to catch up even more!
I don’t think it’s really that surprising. git didn’t become popular because it was decentralised, it just happened to be. So it stands to reason that part doesn’t get emphasised a ton.
The other big point was local branches. Before DVCS, the concept of a "local branch" was generally not a thing. But now you could suddenly create a branch for each separate issue and easily switch between them while isolating unrelated changes.