Get the top HN stories in your inbox every day.
jonhohle
webstrand
git clone --mirror <remote>
It doesn't include pull requests, when cloning from github, though.
Cheer2171
> 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?
velcrovan
When this kind of “sliding” happens it’s usually because the base implementation was missing functionality. Turns out CLI interfaces by themselves are (from a usability perspective) incomplete for the kind of collaboration git was designed to facilitate.
udev4096
It still blows my mind how git has lost it's original ideas of decentralized development because of github and how github, a for-profit - centralized - close-sourced forge, became the center for lots of important open source projects. We need radicle, forgejo, gitea to catch up even more!
seba_dos1
They are available as refs on the remote to pull though, they just aren't listed so don't end up mirrored either.
paulddraper
Having a web interface was really appreciated by users, it would seem.
cwbriscoe
Wasn't that how it worked before Microsoft bought Github?
floydnoel
wouldn't it be cool to have an open source (maybe even p2p/federated) version of GitHub?
BatteryMountain
I've used this method to make a backup of our 80+ repo's at a previous company, just grab the url's from the api & run the git clone in a for loop. Works great!
mzajc
> “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like.
One remote can also hold more URLs! This is arguably more obscure (Eclipse's EGit doesn't even support it), but works wonders for my workflow, since I want to push to multiple mirrors at the same time.
mckn1ght
Whenever I fork a repo I rename origin to “fork” and then add the parent repo as a remote named “upstream” so i can pull from that, rebase any of my own changes in to, and push to fork as needed.
Multiple remotes is also how you can combine multiple repos into one monorepo by just fetching and pulling from each one, maybe into different subdirectories to avoid path collisions.
svieira
This sounds like submodules, but I'm guessing it's completely orthogonal ... multiple distinct remotes for the same _repository_, all of them checked out to different sub-paths; does that result in all the remotes winding up with all the commits for all the shared repositories when you push, or can you "subset" the changes as well?
undefined
kawsper
I always thought it would have been better, and less confusing for newcomers, if GitHub had named the default remote “github”, instead of origin, in the examples.
mckn1ght
Is this something the remote can control? I figured it was on the local cloner to decide.
Can’t test it now but wonder if this is changed if it affects the remote name for fresh clones: https://git-scm.com/docs/git-config#Documentation/git-config...
tobylane
If I clone my fork, I always add the upstream remote straight away. Origin and Upstream could each be github, ambiguous.
pwdisswordfishy
GitHub could not name it so, because it's not up to GitHub to choose.
seba_dos1
There are places where it does choose, but arguably it makes sense for it to be consistent with what you get when using "git clone".
masklinn
How is it less confusing when your fork is also on github?
matrss
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-<username>.
grimgrin
agreed, you'd need a second name anyway. and probably "origin" and "upstream" is nicer than "github" and "my-fork" because.. the convention seems like it should apply to all the other git hosts too: codeberg, sourcehut, tfs, etc
Sharlin
Git was always explicitly a decentralized, "peer to peer" version control system, as opposed to centralized ones like SVN, with nothing in the protocol itself that makes a distinction between a "server" and a "client". Using it in a centralized fashion is just a workflow that you choose to use (or, realistically, one that somebody else chose for you). Any clone of a repository can be a remote to any other clone, and you can easily have a "git server" (ie. just another directory) in your local filesystem, which is a perfectly reasonable workflow in some cases.
jonhohle
This is a better summary than mine.
There was a thread not to long ago where people were conflating git with GitHub. Git is an incredible tool (after coming from SVN/CVS/p4/source safe) that stands on its own apart from hosting providers.
Sharlin
And GitHub naturally has done nothing to disabuse people of the interpretation that git = GitHub. Meanwhile, the actual raison d'etre for the existence of git of course doesn't use GitHub, or the "pull request" based workflow that GitHub invented and is also not anything intrinsic to git in any way.
JamesLeonis
I have a use case just for this. Sometimes my internet goes down while I'm working on my desktop computer. I'll put my work in a branch and push it to my laptop, then go to a coffee shop to continue my work.
kragen
When I do this I usually push to a bare repo on a USB pendrive.
chipsrafferty
I just copy files on a USB drive
webstrand
It's a little more complex than that. Yes git can work in a peer-to-peer fashion, but the porcelain is definitely set up for a hub-and-spoke model, given how cloning a remote repo only gives you a partial copy of the remote history.
There's other stuff too, like git submodules can't be configured to reference another branch on the local repository and then be cloned correctly, only another remote.
jonhohle
> given how cloning a remote repo only gives you a partial copy of the remote history
When you clone you get the full remote history and all remote branches (by default). That’s painfully true when you have a repo with large binary blobs (and the reason git-lfs and others exist).
Sophira
> given how cloning a remote repo only gives you a partial copy of the remote history
You may be thinking of the optional -depth switch, which allows you to create shallow clones that don't have the full history. If you don't include that, you'll get the full history when cloning.
isaacremuant
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.
eru
Yes, I encourage my co-workers, when pushing to a common repo, to use `$user/$whatever` exactly to have their own namespace. The main selling point I'm making is that it makes cleanup of old branches easier, and less conflict-prone.
Tangentially related: when you have multiple local checkouts, often `git worktree` is more convenient than having completely independent local repository. See https://git-scm.com/docs/git-worktree
lloeki
> “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
I've been considering a bare repo + setting $GITDIR (e.g via direnv) but somehow the dead simple simplicity has trumped the lack of push ability
xk3
What's the benefit of this compared to rsync or scp $hostname:.config/<TAB>?
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
lloeki
> 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.
ompogUe
I often init a bare repo on single-use server's I'm working on.
Then, have separate prod and staging clones parallel to that.
Have a post-commit hook set on the bare repo that automatically pushes updates to the staging repo for testing.
When ready, then pull the updates into prod.
Might sound strange, but for certain clients hosting situations, I've found it allows for faster iterations. ymmv
imron
GitHub is full of git anti-patterns
kragen
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 that I'll just include it here:
#!/bin/sh
set -e
echo -n 'updating... '
git update-server-info
echo 'done. going to dev3'
cd /home/kragen/public_html/sw/dev3
echo -n 'pulling... '
env -u GIT_DIR git pull
echo -n 'updating... '
env -u GIT_DIR git update-server-info
echo 'done.'
This could still fail to update the checkout if it has local changes, but only if they create a merge conflict, and it won't fail to update the bare repo, which is probably what your other checkouts are cloned from and therefore where they'll be pulling from.
kragen
Also bare repositories are a useful thing to put on USB pendrives.
3eb7988a1663
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.
kragen
You can repack your repo before you clone it onto the pendrive, and once it's there you can push and pull to it many times. Granted, pendrives are fast enough these days that copying an entire bundle every time is probably fine.
PantaloonFlames
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
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?
kragen
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.
thyristan
Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?
__MatrixMan__
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.
tianqi
I like this comment. Over the years I've always found that whenever I see others using git, everyone uses it in different way and even for different purposes. This has left me really confused about what is the standard practice of Git exactly.
AdrianB1
This is because people have different needs, Git is trying to cover too many things, there are multiple ways to achieve goals and therefore there is no standard practice. There is no single, standard way to cook chicken breast and that is a way simpler thing.
The solution is to set team/department standards inside companies or use whatever you need as a single contributor. I saw attempts to standardize across a company that is quite decentralized and it failed every time.
skydhash
The Pro Git book is available online for free
kevmo314
This sort of thing is part of the problem. If it takes reading such a long manual to understand how to properly use Git, it's no wonder everyone's workflow is different.
kragen
With previous version-control systems, such as SVN and CVS, I found that pair programming helps a great deal with this problem. I started using Git after my last pair-programming gig, unfortunately, but I imagine it would help there too.
(I started using Git in 02009, with networking strictly over ssh and, for pulls, HTTP.)
imbnwa
This is also vim
haskellshill
> 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.
jancsika
> 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.
rco8786
The majority of drivers DON’T know how to change gears.
You are simultaneously saying that something is not expert level knowledge while acknowledging that most people don’t know it. Strange.
__MatrixMan__
My point is only that the understanding is uneven. I'm ready to debate the merits of subtrees vs submodules but I didn't know the folder thing. Am I weird? Yes, but here is a place where weird is commonplace.
undefined
throwaway2037
> just like knowing that the commits are nodes of a DAG
thwarted
Yes. I've been subject to claims that a single person can't start a project unless and until an official, centralized repo is setup for them. I've responded with "git init is all that is necessary to get started", but they wouldn't hear it.
mewpmewp2
Depends, what's the reasoning? Because technically anyone can start a project even without Git. Or even without a computer. Someone can use a pen to write code on a paper.
Depends on what you mean by "a project". If it's policy related, maybe it's company's policy that all code that is written must be stored in a certain way for multitude of reasons.
thwarted
They don't have a reason. There's no policy that keeps them from doing this. Sure, the whole point is to ultimately have the code in a common place where backups and code review can happen, but if it's a matter of starting something sooner because it takes a few days for the request to flow through to get things set up, they are not constrained by that AT ALL. They can create a git repo with git init immediately, start working, and once the repo is set up in the common area, git push all their work into it. Rather than train people on this, we spend time trying to hasten the common area repo setup time and put additional unneeded burden on the team responsible for that.
udev4096
You are missing the whole point. The OP is mentioning how people are so used to using github, that they are so oblivion on using git offline
fingerlocks
You must work at Microsoft? A pound of paperwork for every new repo really shuts down experimental side projects. I showed my colleagues that we can share code via ssh or (painfully) one-drive anytime instead. They reacted like I was asking them to smoke crack behind the dumpsters. “That’s dangerous, gonna get in trouble, no way bro”
mewpmewp2
If you are working in a large corp and not your own side project, that honestly does sound like a bad idea.
paradox460
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
t_mahmood
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 `Codeberg`
With `tailscale`, I feel we have so much options now, instead of putting our personal computer out on the Internet.
crazygringo
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 can attest from personal experience (as many people can) that it will get corrupted. I've heard theories that somehow the file operations get applied out of order somewhere in the pipeline.
WorldMaker
Among other reasons, the sync engines of these cloud stores all have "conflict detection" algorithms when multiple machines touch the same files, and while a bare repo avoids conflicts in the worktree by not having a worktree, there are still a lot of files that get touched in every git push: the refs, some of the pack files, etc.
When it is a file conflict the sync engines will often drop multiple copies with names like "file (1)" and "file (2)" and so forth. It's sometimes possible to surgically fix a git repo in that state by figuring out which files need to be "file" or "file (1)" or "file (2)" or whatever, but it is not fun.
In theory, a loose objects-only bare repo with `git gc` disabled is more append-only and might be useful in file sync engines like that, but in practice a loose-objects-only bare repo with no `git gc` is not a great experience and certainly not recommended. It's probably better to use something like `git bundle` files in a sync engine context to avoid conflicts. I wonder if anyone has built a useful automation for that.
ics
With bare repos? I was bit by this a few years ago when work switched to "everything on OneDrive" and it seemed fine until one day it wasn't. Following that I did tests with Dropbox and iCloud to find that all could corrupt a regular repo very easily. In the past few months though I've been trying it again with bare repos on iCloud and not had an issue... yet.
kragen
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.
t_mahmood
Interesting, so, I will have to keep this in mind if I ever want to do it again.
What about SyncThing?
politelemon
Also relatively unknown: You can clone from a directory. It won't accomplish the backup feature but it's another option/feature.
undefined
superdisk
If you do it over NFS or whatever then you can collaborate as well.
mvanbaak
git over nfs ... not the very best idea.
undefined
ryandv
Filesystems and folders are foreign and elusive concepts to gen Z.
https://www.theverge.com/22684730/students-file-folder-direc...
liveoneggs
I have encountered it in real life many times. These days I try to give jr's extra space to expose their gaps in things I previously assumed were baseline fundamentals - directories and files, tgz/zip files, etc
andai
It gets better than that...
Izkata
A tip, you can put the hash in a regular youtube URL to get the full interface instead of the limited shorts one: https://www.youtube.com/watch?v=D1dv39-ekBM
undefined
liveoneggs
most people think git = github
albert_e
IT support and cybersecurity teams responsible for blocking and enforcing network access restriction to "github.com" ... blocked a user request to install "git" locally citing the former policy. The organization in question does IT services, software development, and maintenance as their main business.
watwut
Sometimes I feel like IT and security people compete on how to make the work least possible.
These guys won.
jiggawatts
That’s… special.
setopt
Yup. I’ve heard several people say that Git is a product from Microsoft…
devsda
I wouldn't mind it if those people are from non-tech background.
Now, if it is a growing misconception among cs students or anyone doing software development or operations, that's a cause for concern.
littlecranky67
The irony, when you realize that Linus Torvalds created git.
ruguo
Looks like they’re not developers after all
bfkwlfkjf
Nonsense...
Even someone who knows that git isn't GitHub might not be aware that ssh is enough to use git remotely. That's actually the case for me! I'm a HUGE fan of git, I mildly dislike GitHub, and I never knew that ssh was enough to push to a remote repo. Like, how does it even work, I don't need a server? I suspect this is due to my poor understanding of ssh, not my poor understand of git.
porridgeraisin
> I don't need a server?
You do, an SSH server needs to be running on the remote if you want to ssh into it, using your ssh client - the `ssh` command on your laptop. It's just not a http server is all.
You start that server using the `sshd` [systemd] service. On VPSs it's enabled by default.
Git supports both http and ssh as the "transport method". So, you can use either. Browsers OTOH only support http.
skydhash
Git is distributed, meaning every copy is isolated and does not depends on other's copy. Adding remotes to an instance is mostly giving a name to an URL(URI?) for the fetch, pull, push operation, which exchange commits. As Commits are immutable and forms a chain, it's easy to know when two nodes diverge and conflict resolution can take place.
From the git-fetch(1) manual page:
> Git supports ssh, git, http, and https protocols (in addition, ftp and ftps can be used for fetching, but this is inefficient and deprecated; do not use them).
You only need access to the other node repo information. There's no server. You can also use a simple path and store the other repo on drive.
liveoneggs
Did you know that you can use git locally? It works just like that because ssh is a remote shell.
Read https://git-scm.com/docs/git-init#Documentation/git-init.txt...
Anyway it sounds like you have a lot of holes in your git-knowledge and should read some man pages
Joeboy
I mean, you do need an ssh server. Basically ssh can run commands on the remote machine. Most commonly the command would be a shell, but it can also be git commands.
halJordan
I always found these sort of categorical denigrations to be off base. If most people do think git = github then that's because they were taught it by somebody. A lot of somebodies for "most people". Likely by the same somebodies who also come to places like this. It has always taken a village to raise a child and that is just as true for an infant as a junior programmer. But instead we live in a sad world of "why didn't schools teach person x"
loloquwowndueo
Despite your indignation, the observation that most people think GitHub is git is entirely true. Do you point it out when you spot someone having that mistaken belief? I do.
Dylan16807
What makes you say that people complain about the spread of incorrect knowledge "instead" of teaching? Because there's nothing wrong with doing both.
liveoneggs
they were taught by github
bfkwlfkjf
[flagged]
blueflow
Humans are fallible, relying on hearsay is unprofessional, learn your craft properly.
Imagine what the equivalent argumentation for a lawyer or nurse would be. Those rules ought to apply for engineers, too.
mewpmewp2
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 may have thought that maybe there must be some sort of git server process running that would handle it, although it's plausible that it would be possible to just do a script that would handle it from the client side.
And finally, I would've never thought really to necessarily try it out like that, since I've always been using Github, Bitbucket, etc. I have thought of those as permanent, while any boxes I have could be temporary, so not a place where I'd want to store something as important to be under source control.
Klonoar
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…?
mewpmewp2
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.
undefined
jrm4
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.
pixelmonkey
This reminded me of another discussion on HN a few months ago. Wherein I was reflecting on how the entire culture of internet standards has changed over time:
"In the 80s and 90s (and before), it was mainly academics working in the public interest, and hobbyist hackers. Think Tim Berners-Lee, Vint Cerf, IETF for web/internet standards, or Dave Winer with RSS. In the 00s onward, it was well-funded corporations and the engineers who worked for them. Think Google. So from the IETF, you have the email protocol standards, with the assumption everyone will run their own servers. But from Google, you get Gmail.
[The web] created a whole new mechanism for user comfort with proprietary fully-hosted software, e.g. Google Docs. This also sidelined many of the efforts to keep user-facing software open source. Such that even among the users who would be most receptive to a push for open protocols and open source software, you have strange compromises like GitHub: a platform that is built atop an open source piece of desktop software (git) and an open source storage format meant to be decentralized (git repo), but which is nonetheless 100% proprietary and centralized (e.g. GitHub.com repo hosting and GitHub Issues)." From: https://news.ycombinator.com/item?id=42760298
jrm4
Yes. And honestly though, this is the sort of thing that makes me generally proclaim that Free Software and Open Source won.
It was extremely unlikely that it would be some kind of free utopia; but also, it's extremely remarkable what we've been able to keep generally free, or at least with a free-enough option.
unethical_ban
I'd say GitHub is to git what Facebook is to email.
GitHub's value is in network effects and features like big and issue tracking.
At least Gmail is still an email client that communicates with other systems.
m3047
DNS is in the same predicament. :-p
morshu9001
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.
kragen
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.
jrm4
It's not a "CLI" and yes, "decentralized" was literally one of the points of it.
morshu9001
"Distributed" was the point and the language their site uses*, not decentralized. It's only described as a convenience and reliability thing in contrast to the mess known as CVS. I haven't seen a note about avoiding one entity having too much power, even if that's a goal some users have in mind. Normally you have one master repo, or "blessed" as the site calls it.
It's like, a Redis cluster is distributed but not decentralized. The ssh protocol is not decentralized. XMPP, Matrix, and Bitcoin are decentralized protocols, first two via federation.
ashton314
Git was explicitly designed to be decentralized.
semanticc
Linux is not developed in GitHub.
morshu9001
I know it's only a mirror, but it looks like an approval
eqvinox
git clone ssh://username@hostname/path/to/repo
git clone username@hostname:path/to/repo
git clone hostname:path/to/repo
DrNefario
Git also respects your `~/.shh/config`, which lets you change settings per host. I've set up each of my GitHub accounts with a different "host" so it's easy to switch between them.
mlrtime
I never thought about this.. I've had the following problem in the past.
Host A, cannot reach official github.com. But Host B can and has a local copy of a repo cloned. So Host B can 'git clone ssh://' from Host A which is essentially equivalent, but just setting origin to Host B instead of github.com, sort of acting as a manual proxy?
What if Host A is natted, so Host B can ssh to Host A but not the reverse, can Host G ssh clone to Host A to push changes?
In the rare times I've needed this, I just 'rsync -av --delete' a repo from B->A.
eqvinox
You might want to read the documentation on "git remote". You can pull/fetch and push between repos quite arbitrarily, with plain ssh.
undefined
seba_dos1
Just make the repository on the server side bare and you won't have to worry about checked out branches or renaming ".git" directory.
cl3misch
> 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.
kragen
See https://news.ycombinator.com/item?id=45713074 for a worked example of how it works with a bare repo.
liveoneggs
yeah it seems odd that they don't just have remote> $HOME/repos/foo.git and then clone from there locally and remotely
seba_dos1
FWIW a single user working on a remote versioned directory is indeed a reasonable use-case for receive.denyCurrentBranch=updateInstead, but IMO the article should have made it clear that it's not necessarily a good choice in general.
imiric
I've used Git over SSH for several years for personal projects. It just works with no additional overhead or maintenance.
Tip: create a `git` user on the server and set its shell to `git-shell`. E.g.:
sudo useradd -m -g git -d /home/git -s /usr/bin/git-shell git
Then, when you need to create a new repository you run:
sudo -u git git init --bare --initial-branch=main /home/git/myrepo.git
git clone git@myserver:myrepo.git
git remote add myserver git@myserver:myrepo.git
git push -u myserver main
I think that initializing a bare repository avoids the workarounds for pushing to a currently checked out branch.
amelius
Yes, that's how I use it too.
However, this setup doesn't work with git-lfs (large file support). Or, at least I haven't been able to get it working.
PS: Even though git-shell is very restricted you can still put shell commands in ~/git-shell-commands
matrss
To my knowledge git-lfs is only really designed to store your large files on a central server. I think it also uses its own out-of-band (from the perspective of git) protocol and connection to talk to that server. So it doesn't work with a standard ssh remote, and breaks git's distributed nature.
For an actually distributed large file tracking system on top of git you could take a look at git-annex. It works with standard ssh remotes as long as git-annex is installed on the remote too (it provides its own git-annex-shell instead of git-shell), and has a bunch of additional awesome features.
general1465
Yes exactly, creating git user on Linux machine and configuring it just for git turned out to be easiest way how to get Source Tree and Git in Windows work with it out of the box.
ninkendo
I remember the first time I tried git, circa 2006, and the first 3 commands I tried were:
git init
git commit -am Initial\ commit
git clone . ssh://server/path/to/repo
Bitkeeper and a few other contemporaries would let you just push to a remote path that doesn’t exist yet and it’d create it. Maybe git added this since then, but at the time it seemed like a huge omission to me.
seba_dos1
Hah, you made me check whether clone's second argument can be a URL. But no, it's explicitly "<directory>", so it can't be used as a equivalent of "git push --mirror" :)
undefined
HumanOstrich
[flagged]
ninkendo
Lol I have no idea why you came away with “… and I never used git again!” from all that.
I love git. It’s unironically one of my favorite pieces of software in the world. I’ve used it nearly every day for almost 20 years.
Maybe take a break from HN for a bit, I mean that sincerely.
bitbasher
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.
zyxin
I sent over a cgit web page for a take home assessment and the interviewer was horribly confused. I assume they have never seen anything apart from github before...
bitbasher
I imagine the interviewer was one of those senior developers that still thinks git == github.
LambdaComplex
Huh, I never realized that cgit was created by the same person that created wireguard.
undefined
prmph
The more I use git, the more I discover more depth to it.
So many features and concepts; it's easy to think you understand the basics, but you need to dig deep into it's origin and rationale to begin to grasp the way of thinking it is built around.
And the API surface area is much larger than one would think, like an iceberg
So I find it really weirdly low level in a way. Probably what is needed is is a higher-level CLI to use it in the most sensible, default way, because certainly the mental model most people use it with is inadequate.
tonymet
My favorite git trick is using etckeeper & git subtree to manage multiple machines from a single repo . A single git repo can “fan out” to dozens of instances . It’s useful even for “managed” hosts with terraform because etckeeper snapshots config with every change, catching bugs in the terraform config.
During the dev / compile / test flow, git makes a lightweight CI that reduces the exposure to your primary repo . Just run `watch -n 60 make` on the target and push using `git push` . The target can run builds without having any access to your primary (GitHub) repo.
dlisboa
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.
tonymet
`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/
Then add the subtree with `git subtree add -P machine1/etc hosts/machine1/etc master`
When you want to pull changes you can `git subtree pull` or `git subtree push …`
If you end up making changes in your monorepo, use push. If you make changes directly on the machine (or via terraform), pull
This way you can edit and manage dozens of machines using a single git repo, and git subtree push to deploy the changes. No deploy scripts.
dlisboa
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.
tonymet
I call it “fan out” because it allows one repo to fan out to many deployments. The monorepo can be pushed to GitHub/gitlab and backed up regularly. It’s a lot easier to manage one big repo than dozens of tiny ones. And it helps with dependencies across machines. You can version control the entire network using the repo git commit.
simonw
> 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 on your own server such that any pushes are then pushed to a GitHub copy without you having to do anything else yourself.
nicce
> 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.
simonw
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.
nicce
> 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.
None of that protects against the U.S. laws or current political climate. There is no guarantee for EU citizen that GitHub processes data only in EU area or that data ever leaves it. So it is all about the data privacy.
lionkor
That's not accurate. I've had one of my own accounts blocked, with zero access until I talked to their support and convinced them I was, in fact, a real person.
At that moment, if I had any important private repos, they would be gone.
Get the top HN stories in your inbox every day.
I feel like something was lost along the way.
will give you a git repo without a working set (just the contents typically in the .git directory). This allows you to create things like `foo.git` instead of `foo/.git`.“origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like. You can even namespace where you push back to the same remotes by changing fetch and push paths. At one company it was common to push back to `$user/$feature` to avoid polluting the root namespace with personal branches. It was also common to have `backup/$user` for pushing having a backup of an entire local repo.
I often add a hostname namespace when I’m working from multiple hosts and then push between them directly to another instead of going back to a central server.
For a small static site repo that has documents and server config, I have a remote like:
So I can push from my computer directly to that server, but those branches won’t overwrite the server’s branches. It acts like a reverse `git pull`, which can be useful for firewalls and other situations where my laptop wouldn’t be routable.