Live data from Hacker News

You already have a Git server

maurycyz.com

441–450 of 454 posts

Re: You already have a Git server

#441
post #389

Earlier quoted context omitted.

Git pull is git fetch plus git merge.

I've run into so many people that think "git pull" doesn't do anything unless you run "git fetch" first. In my 10+ year career, I'm not sure I've ever run "git fetch" manually. I've never had a time where I wanted to fetch upstream changes, but not merge (or rebase) them into my branch.

Yeah, I don't remember having done that either. But I've often had changes where the merge failed because of un-checked-in changes, and then it was convenient to be able to run `git merge` after checking in the changes rather than `git pull` because it didn't need to talk to the remote.

Re: You already have a Git server

#442
post #428
post #383

Earlier quoted context omitted.

> “origin” is also just the default name for the cloned remote I don't have a central dotfiles repo anymore (that I would always to forget to push to); I have SSH access to my devices - via tailscale - anyway so I'm doing git remote add $hostname $hostname:.config and can cd ~/.config && git fetch/pull/rebase $hostname anytime from anywhere. I've been considering a bare repo + setting $GITDIR (e.g via direnv) but som…

What's the benefit of this compared to rsync or scp $hostname:.config/ ? I put my whole home folder in git and that has its benefits (being able to see changes to files as they happen) but if I'm just copying a file or two of config I'll just cat or scp it--introducing git seems needlessly complex if the branches are divergent

> just a file or two

I don't have to remember which to copy

> rsync or scp

I don't have to remember which is most recent, nir even assume that "most recent" is a thing (i.e nonlinear)

It's all just:

- a git fetch --all away to get

- a git log --oneline --decorate --graph --all to find out who's where and when

- diff and whatchanged for contents if needed

- a cherry-pick / rebase away to get what I want, complete with automatic conflict resolution

I can also have local experiments in local topic branches, things I want to try out but not necessarily commit to across all of my machines yet.

Re: You already have a Git server

#443

Earlier quoted context omitted.

Care to share a little bit more about this? I've been thinking of using git with `--work-tree=/` to track system files, so I'm interested in these "unusual" setups with git. Not sure I got the "fan out" concept here.

`apt install etckeeper` will setup a repo in /etc/.git for you. It tracks any changes made via apt, and it runs nightly for other changes. On your primary repo, create dirs for each machine e.g. monorepo/ ├─ Machine1/ │ ├─ usr/share/www/ │ ├─ etc/ ├─ machine2/ │ ├─ etc/ Create remotes for each machine+repo e.g. `git remote add hosts/machine1/etc ssh://machine1/etc` then `git fetch hosts/machine1/etc` Then add the sub…

Thanks, this sounds interesting. I wasn’t aware of etckeeper. So I take it you do periodic git pulls to update files and keep it all in check.

The idea of a folder per machine is very good.

Re: You already have a Git server

#444

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…

Interesting, so, I will have to keep this in mind if I ever want to do it again.

What about SyncThing?

Re: You already have a Git server

#445

So my friend and I were trying to learn some coding together. We had our laptops on the same wifi and I wanted us to use git without depending on GitHub, but I was completely stumped as to how to actually connect us together. I don't want us to setup SSH servers on each other's laptops, giving each other full access to our computers, and sending patches to each other across the living room seems overkill when we're j…

Just use netcat and send a git bundle across?

Or if you are using Linux, there is a httpd (web server) in the busybox package:

  busybox httpd -f -p 0.0.0.0:10080 -h ~/public/

Re: You already have a Git server

#446

Earlier quoted context omitted.

> It doesn't include pull requests, when cloning from github, though. Because GitHub pull requests are a proprietary, centralized, cloud-dependent reimplementation of `git request-pull`. How the "free software" world slid head first into a proprietary cloud-based "open source" world still boils my blood. Congrats, Microsoft loves and owns it all, isn't that what what we always wanted?

wouldn't it be cool to have an open source (maybe even p2p/federated) version of GitHub?

afaik Forgejo is working on integrating it:

- https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo

- https://forgefed.org/

Re: You already have a Git server

#447

Earlier quoted context omitted.

`apt install etckeeper` will setup a repo in /etc/.git for you. It tracks any changes made via apt, and it runs nightly for other changes. On your primary repo, create dirs for each machine e.g. monorepo/ ├─ Machine1/ │ ├─ usr/share/www/ │ ├─ etc/ ├─ machine2/ │ ├─ etc/ Create remotes for each machine+repo e.g. `git remote add hosts/machine1/etc ssh://machine1/etc` then `git fetch hosts/machine1/etc` Then add the sub…

Thanks, this sounds interesting. I wasn’t aware of etckeeper. So I take it you do periodic git pulls to update files and keep it all in check. The idea of a folder per machine is very good.

That’s right and git helps with that too, like any repo. It will warn you when the target is dirty , or you haven’t pulled the latest changes. So you don’t need to do the mental bookkeeping.

Re: You already have a Git server

#448

Earlier quoted context omitted.

`apt install etckeeper` will setup a repo in /etc/.git for you. It tracks any changes made via apt, and it runs nightly for other changes. On your primary repo, create dirs for each machine e.g. monorepo/ ├─ Machine1/ │ ├─ usr/share/www/ │ ├─ etc/ ├─ machine2/ │ ├─ etc/ Create remotes for each machine+repo e.g. `git remote add hosts/machine1/etc ssh://machine1/etc` then `git fetch hosts/machine1/etc` Then add the sub…

Thanks, this sounds interesting. I wasn’t aware of etckeeper. So I take it you do periodic git pulls to update files and keep it all in check. The idea of a folder per machine is very good.

And let me know what you end up doing with it. I’ve been thinking about making an “unconventional git patterns” site because I love it so much and it’s so under-utilized.

Re: You already have a Git server

#449
post #319

Earlier quoted context omitted.

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…

Agreed. Back when I first came across git in 2009 I had to re-read the porcelain manual 3 times before I really got it, but then the conceptual understanding has been useful ever since. I have often the guy explaining git to newbies on my team.

There's a lot more porcelain to document than there was then; maybe that's a less useful approach now.
Post reply on HN