311–320 of 454 posts
One note, xcode and maybe some other clients can't use http "dumb mode". Smart mode is not hard to set up, but it's a few lines of server config more than this hook. TIL about the update options for checked out branch. In practise though usually you want just the .git "bare" folder on server
Earlier quoted context omitted.
Yes, when you're not on NFS. Maybe it works on NFS but I wouldn't bet my project on it. Locking reliably on NFS is easy to get wrong, and it's a comparatively little-tested scenario now compared to 30 years ago. (You'll notice that the question doesn't even mention the possibility of NFS.) Fortunately at least with Git it's easy to have lots of backups.
For what it's worth they do call it out in the manual as a common thing to do: https://git-scm.com/book/ms/v2/Git-on-the-Server-The-Protoco... Granted I've never tried it so take it with a grain of salt.
Earlier quoted context omitted.
Also bare repositories are a useful thing to put on USB pendrives.
For a USB drive, I would be more likely to use a bundle. Intended for offline distribution of a repository. Plus it is a single file, so you do not have to pay the transfer overhead of many small files.
Earlier quoted context omitted.
>Having a web interface It's not the interface , it's the web hosting . People want a free destination server that's up 24/7 to store their repository. If it was only the web interface, people could locally install GitLab or Gitea to get a web browser UI. (Or use whatever modern IDE code editor to have a GUI instead of a CLI for git commands.) But doing that still doesn't solve what GitHub solves: a public server to…
It was both. A 24/7 repository and a 24/7 web URL for the code. Those two features together let devs inspect and download code, and open and discuss issues. The URL also let automated tools download and install packages. Familiar UI, network effects made the rest.
I'm really looking forward to federated forges.
Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?
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 `…
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 can attest from personal experience (as many people can) that it will get corrupted. I've heard theories that somehow the file operations get applied out of order somewhere in the pipeline.
> It’s also backed up by default: If the server breaks, I’ve still got the copy on my laptop, and if my laptop breaks, I can download everything from the server. This is true, but I do also like having backups that are entirely decoupled from my own infrastructure. GitHub personal private accounts are free and I believe they store your data redundantly in more than one region. I imagine there's a way to setup a hook…
For most people, that would defeat the purpose of self-hosting.
Earlier quoted context omitted.
> Turns out CLI interfaces by themselves are (from a usability perspective) incomplete for the kind of collaboration git was designed to facilitate. git was designed to facilitate the collaboration scheme of the Linux Kernel Mailing List, which is, as you might guess... a mailing list. Rather than a pull-request (which tries to repurpose git's branching infrastructure to support collaboration), the intended unit of i…
I'm assuming a "patch" is a group of commits. So would a "patch series" be similar to GitLabs notion of dependent MRs?
Earlier quoted context omitted.
It's not. Unless you work at a shitty place, something like what OP mentioned is far from a big deal and most people would wanna know more about it
The code is considered IP of the corp and they probably have rules around how or where IP should be shared, access controls etc.
It's a misguided policy that hurts morale and leaves a tremendous amount of productivity and value on the floor. And I suspect that many of the policies are in place simply because a number of the rule makers aren't aware of how easy it to share the code. Look how many in this thread alone weren't aware of inherent distributability of git repositories, and presumably they're developers. You really think some aging career dev ops that worked at Microsoft for 30 years is going to make sensical policies about some software that was shunned and forbidden only a decade ago?
Earlier quoted context omitted.
The Pro Git book is available online for free https://git-scm.com/book/en/v2
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.
Unlike calculus, though, you can learn enough about Git to use it usefully in ten minutes. Maybe this sets people up for disappointment when they find out that afterwards their progress isn't that fast.
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…