Live data from Hacker News

You already have a Git server

maurycyz.com

301–310 of 454 posts

Re: You already have a Git server

#301

Earlier quoted context omitted.

I'd say git submodules have such an awkward UX that should probably not be used except in very rare and organized cases. I've done it before but it has to be worth it. But I get your larger point.

And they're often (not always) used where subtrees would fit better.

I can't get over my fear of subtrees after accidentally nuking one of my repos by doing a rebase across the subtree commit. I've found that using worktrees, with a script in the main branch to set up the worktrees, works pretty well to split history across multiple branches, like what you might want in a monorepo.

Sadly doing a monorepo this way with pnpm doesn't work, since pnpm doesn't enforce package version requirements inside of a pnpm workspace. And it doesn't record installed version information for linked packages either.

Re: You already have a Git server

#302

Earlier quoted context omitted.

It doesn't matter. They are centralized on servers that are ssh accessible, creating it is effectively mkdir and git init. It's not about how long the action takes, it's about how much the team responsible for that is loaded and can prioritize things. Every team needs more round tuits. Anyone who works in an IT support role knows this. The point is that they can self-service immediately and there is no actual depende…

But why can't the teams themselves do it? All places I've seen or been to have had teams able to create their own repositories, either they use cloud Git providers like Bitbucket, Gitlab or Github, or they have self hosted Gitlab, Github etc.

[deleted]

Re: You already have a Git server

#303
post #237
post #196

You probably want to use a bare repository (git init --bare) rather than `git config receive.denyCurrentBranch updateInstead`, which will cause your pushes to fail if you edit anything locally in the checkout. For http://canonical.org/~kragen/sw/dev3/ I run a pull from the post-update hook of http://canonical.org/~kragen/sw/dev3.git , http://canonical.org/~kragen/sw/dev3.git/hooks/post-update , which is short enough…

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.

Re: You already have a Git server

#304
post #224

Earlier quoted context omitted.

Having a web interface was really appreciated by users, it would seem.

>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.

Re: You already have a Git server

#305
post #275

Earlier quoted context omitted.

Shared write access to the same git repo directory can be done sanely, but you have to get a number of things right (same group for all users, everything group writable, sticky bit on directories, set config core.sharedRepository=group): https://stackoverflow.com/a/29646155

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.

Re: You already have a Git server

#306
post #149

Cannot emphasize this whole notion enough; Very roughly, Github is to git what gmail is to email. It's mostly probably fine if that's the thing most of everybody wants to use and it works well; but also it's very unwise to forget that the point was NEVER to have a deeply centralized thing -- and that idea is BUILT into the very structure of all of it.

Idk if git was designed to not be used in a centralized way. Like all other common CLIs, it was simply designed to work on your PC or server without caring who you are, and nothing stopped a corp from turning it into a product. Torvalds made git and Linux, then he put Linux on Github.

The reason Linus wrote Git was specifically because he was unwilling to accept the centralization of the existing popular source-control systems like CVS and SVN, and Linux's license to the unpopular proprietary decentralized source control system it was using got revoked because Larry McVoy threw a tantrum. Linus needed an open-source alternative, so he tried the unpopular open-source source-control systems like Monotone, but he felt they suffered from both featuritis and inadequate performance, so he wrote a "stupid content tracker" called Git.

Re: You already have a Git server

#307

Just make the repository on the server side bare and you won't have to worry about checked out branches or renaming ".git" directory.

> This is a great way to [...] work on server-side files without laggy typing or manual copying This is the usecase mentioned in the article and it wouldn't work with a bare repo. But if the server your SSH'ing to is just a central point to sync code across machines, then you're right: multiple hoops mentioned in the article are solved by having the central repo bare.

See https://news.ycombinator.com/item?id=45713074 for a worked example of how it works with a bare repo.

Re: You already have a Git server

#308

Earlier quoted context omitted.

Please, elaborate. I can share my screen with coworkers and talk about all sorts of confidential things, and I can even give them full remote access to control everything if I wished. So why would pushing a some plain text code directly to their machine be so fundamentally different than all the other means of passing bits between our machines?

If you share screen you are in control of what you show, if you give someone SSH access, what would stop them from passing/running a small script to fetch everything you have or doing w/e with your computer? I mean it's a blatant security violation to me. Just no reason to do that. In large corps you usually have policies to not leave your laptop unattended logged in, in the office, that would be potentially even wor…

I wasn't aware that I could run a small script and fetch everything from every host with an ssh git repo. TIL.

Re: You already have a Git server

#309

Beware of using this to publish static sites: you can accidentally expose your .git directory to the public internet. I got pwned this way before (by a pentester fortunately). I had to configure Apache to block the .git directory.

I expose my .git directory to the public internet on purpose. If I don't, how will anyone else clone the repo?

Re: You already have a Git server

#310
post #210

Back when I started at my current job... 15 years ago... We had no central git server. No PR workflow. We just git pull-ed from each others machines. It worked better than you would expect. We then went to using a central bare repo on a shared server, to hosted gitlab(? I think - it was Ruby and broke constantly) eventually landing on GitHub

This is classic git usage. A "pull request" was literally just asking someone to pull from your branch. GitHub co-opted the term for their own thing. The thing that people really don't seem to get these days is how your master branch is a different branch from someone else's master branch. So pulling from one master to another was a normal thing. When you clone you get a copy of all the branches. You can commit to yo…

On GitHub, too, a "pull request" is literally just asking someone to pull from your branch.
Post reply on HN