Live data from Hacker News

You already have a Git server

maurycyz.com

271–280 of 454 posts

Re: You already have a Git server

#271

Earlier quoted context omitted.

If you are working in a large corp and not your own side project, that honestly does sound like a bad idea.

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 worse than that.

Re: You already have a Git server

#272
post #20

As a git user "not by choice" (my preference going for mercurial every single day), I never understood why git needs this distinction between bare/non-bare (or commit vs staging for that matter). Seems like yet another leaky abstraction/bad design choice.

Jujutsu make the interaction sane, and is far more logical than even mercurial (that I love too!)

Re: You already have a Git server

#274

Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?

In the past I've blown coworkers minds during github outages when I just pulled code from a co-worker's machine and kept working

With remote, if your company stubbornly refuses to use a modern vpn like tailscale, and you can't really network between two computers easily, git format patch and git am, coupled with something like slack messages, works well enough, albeit moderately cumbersome

Re: You already have a Git server

#275
post #242

Earlier quoted context omitted.

I haven't tried it, but I think it's fine if only one person has write access to any given clone. You can pull back and forth between clones freely. It's if you have two Git clients trying to write to the same repo that you'll have problems.

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.

Re: You already have a Git server

#276

Earlier quoted context omitted.

Depends on what you mean by using etc. If somebody asked me if it's possible to scp my git repo over to another box and use it there or vice versa, I would have said, yes, that is possible. Although I would've felt uneasy doing that. If somebody asked me if git clone ssh:// ... would definitely work, I wouldn't have known out of the gate, although I would have thought it would be neat if it did and maybe it does. I m…

Am I misreading your comment? You’ve always used GitHub but never known it could work over ssh? Isn’t it the default method of cloning when you’re signed in and working on your own repository…?

I have used SSH for GitHub of course, but the thought that I could also use it from any random machine to machine never occurred to me. And when it might occur to me, I would have thought that maybe SSH is used as a mechanism for authentication, but it might still require some further specialized server due to some unknown protocols of mine. I always thought of SSH or HTTPS as means of authentication and talking to the git server rather than the thing that processes cloning.

E.g. maybe the host would have to have something like apt install git-server installed there for it to work. Maybe it wouldn't be available by default.

I do know however that all info required for git in general is available in the directory itself.

Re: You already have a Git server

#277
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…

regarding that post-update script, can you explain? I would think you'd want to cd /home/kragen/public_html/sw/dev3 git update-server-info git pull ..in that order. And I wouldn't think you'd need to run git update-server-info again, after git pull. My understanding isthe update-server-info makes updates to info/refs , which is necessary _after a push_. What am I missing?

The first update-server-info is running in the bare repo, which is the place I just pushed to, which is where sw/dev3 is going to pull from.

I'm not sure the second update-server-info is necessary.

If you're asking about the env -u, that's because Git sets that variable so that commands know which repo they're in even if you cd somewhere else, which is exactly what I don't want.

Re: You already have a Git server

#278

I have been doing this for many years. If you want a public facing "read only" ui to public repositories you can use cgit ( https://git.zx2c4.com/cgit/about/ ) to expose them. That will enable others to git clone without using ssh. I keep my private repositories private and expose a few public ones using cgit.

Huh, I never realized that cgit was created by the same person that created wireguard.

Re: You already have a Git server

#279
post #236
post #178

How would I sync access, if more than one people ssh-pushes onto the git repo? I assume syncing be necessary.

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?

Re: You already have a Git server

#280

Earlier quoted context omitted.

I've been using git since 2007, this only dawned on me last year. Git is especially prone to the sort of confusion where all the experts you know use it in slightly different ways so the culture is to just wing it until you're your own unique kind of wizard who can't tie his shoes because he favors sandals anyhow.

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

> It's a strange situation, it'd be like if a majority of drivers didn't know how to change gears.

If you literally can't change gears then your choices are a) go nowhere (neutral), b) burn out your clutch (higher gears), or c) burn out your engine (1st gear). All are bad things. Even having an expert come along to put you in the correct gear once, twice, or even ten times won't improve things.

If a programmer doesn't know that git is a folder or that the commits are nodes of a DAG, nothing bad will happen in the short term. And if they have a git expert who can get them unstuck say, five times total, they can probably make it to the end of their career without having to learn those two details of git.

In short-- bad analogy.

Post reply on HN