Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You already have a Git server

maurycyz.com

Post reply on HN
Print view View original

321–330 of 454 posts

Re: You already have a Git server

#321

Post by kragen »

mewpmewp2 wrote: post #276
Klonoar wrote: post #207

Earlier quoted context omitted.

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 t…

Yes, SSH is used as a mechanism for authentication, and it still requires some further specialized server due to some protocols you don't know about. The server is git-upload-pack or git-receive-pack, depending on whether you're pulling or pushing. Your inference that a Linux distribution could conceivably put these in a separate package does seem reasonable, since for example git-gui is a separate package in Debian. I don't know of any distros that do in fact package Git that way, but they certainly could.

Re: You already have a Git server

#322

Post by crazygringo »

kragen wrote: post #320
crazygringo wrote: post #315

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…

I've had a lot of success with using whatever. A lot of whatevers can quite handle many hundreds of file operations 100.0000% correctly.

Ha. I guess for me the other whatever is iCloud, but that corrupts too.

But have you ever found a cloud sync tool that doesn't eventually corrupt with git? I'm not aware of one existing, and I've looked.

Again, to be clear, I'm not talking about the occasional rsync, but rather an always-on tool that tries to sync changes as they happen.

Re: You already have a Git server

#324

Post by simonw »

nicce wrote: post #316
simonw wrote: post #203

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

> 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 self-host so that they're not dependent on GitHub up-time or having their accounts banned and losing access to their data. For them, having a secondary GitHub backup should still be useful.

Re: You already have a Git server

#325

Post by matrss »

kragen wrote: post #238
matrss wrote: post #171

Earlier quoted context omitted.

Requiring a fork to open pull requests as an outsider to a project is in itself a idiosyncrasy of GitHub that could be done without. Gitea and Forgejo for example support AGit: https://forgejo.org/docs/latest/user/agit-support/ . Nevertheless, to avoid ambiguity I usually name my personal forks on GitHub gh- .

No, it's a normal feature of Git. If I want you to pull my changes, I need to host those changes somewhere that you can access. If you and I are both just using ssh access to our separate Apache servers, for example, I am going to have to push my changes to a fork on my server before you can pull them. And of course in Git every clone is a fork. AGit seems to be a new alternative where apparently you can push a new b…

Arguably the OG workflow to submit your code is `git send-email`, and that also doesn't require an additional third clone on the same hosting platform as the target repository.

All those workflows are just as valid as the others, I was just pointing out that the way github does it is not the only way it can be done.

Re: You already have a Git server

#326

Post by kragen »

crazygringo wrote: post #322
kragen wrote: post #320

Earlier quoted context omitted.

I've had a lot of success with using whatever. A lot of whatevers can quite handle many hundreds of file operations 100.0000% correctly.

Ha. I guess for me the other whatever is iCloud, but that corrupts too. But have you ever found a cloud sync tool that doesn't eventually corrupt with git? I'm not aware of one existing, and I've looked. Again, to be clear, I'm not talking about the occasional rsync, but rather an always-on tool that tries to sync changes as they happen.

I was thinking of my pendrive, but apparently https://news.ycombinator.com/item?id=45714245 it also works on NFS.

Re: You already have a Git server

#327

Post by kragen »

matrss wrote: post #325
kragen wrote: post #238

Earlier quoted context omitted.

No, it's a normal feature of Git. If I want you to pull my changes, I need to host those changes somewhere that you can access. If you and I are both just using ssh access to our separate Apache servers, for example, I am going to have to push my changes to a fork on my server before you can pull them. And of course in Git every clone is a fork. AGit seems to be a new alternative where apparently you can push a new b…

Arguably the OG workflow to submit your code is `git send-email`, and that also doesn't require an additional third clone on the same hosting platform as the target repository. All those workflows are just as valid as the others, I was just pointing out that the way github does it is not the only way it can be done.

Yes, that's true. Or git format-patch.

Re: You already have a Git server

#328

Post by scuff3d »

kragen wrote: post #317
scuff3d wrote: post #285

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?

You normally have one patch per commit. The patch is the diff between that commit and its parent. (I forget how git format-patch handles the case where there are two parents.)

If that's the case I'm assuming the commit itself is quite large then? Or maybe it would more accurate to say it can be large if all the changes logically go together?

I'm thinking in terms of what I often see from people I work with, where a PR is normally made up of lots of small commits.

Re: You already have a Git server

#330

Post by kragen »

scuff3d wrote: post #328
kragen wrote: post #317

Earlier quoted context omitted.

You normally have one patch per commit. The patch is the diff between that commit and its parent. (I forget how git format-patch handles the case where there are two parents.)

If that's the case I'm assuming the commit itself is quite large then? Or maybe it would more accurate to say it can be large if all the changes logically go together? I'm thinking in terms of what I often see from people I work with, where a PR is normally made up of lots of small commits.

The idea is that you divide a large change into a series of small commits that each make sense in isolation, so that Linus or Greg Kroah-Hartman or whoever is looking at your proposed change can understand it as quickly as possible—hopefully in order to accept it, rather than to reject it.
Post reply on HN