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.
You already have a Git server
441–450 of 454 posts
Re: You already have a Git server
#442Earlier 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
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
#443Earlier 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…
The idea of a folder per machine is very good.
Re: You already have a Git server
#444Earlier 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…
What about SyncThing?
Re: You already have a Git server
#445So 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…
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
#446Earlier 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?
Re: You already have a Git server
#447Earlier 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.
Re: You already have a Git server
#448Earlier 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.
Re: You already have a Git server
#449Earlier 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.