git clone --mirror <remote> 

It doesn't include pull requests, when cloning from github, though.

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

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

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.

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.

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

Also bare repositories are a useful thing to put on USB pendrives.

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?

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.

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

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.

I read an article not long ago where students coming out of a web dev bootcamp were unable to make a hello world html file and open it in their browser.

We’ve gone so far with elaborate environments and sets to make it easy to learn more advanced things, that many people never learn the very basics. I see this as a real problem.

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.

Also relatively unknown: You can clone from a directory. It won't accomplish the backup feature but it's another option/feature.

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.

most people think git = github

I don't think it has anything to do with being old, this is what happens when your software gets too complex that nobody even knows the very basics. This is highlighted with the documentation, if the software's documentation becomes lengthy enough that it could be an entire book, you're going to be getting these sorts of articles from time to time. Another highlight is bash, that is a huge man page for what should be a shell.

Yep, me. I noticed that you sometimes use ssh:// URLs for GitHub, but I figured it was for authentication purposes only, and that once that step was over, some other thing came into play.

I didn’t know either - or rather, I had never stopped to consider what a server needs to do to expose a git repo.

But more importantly, I’m not sure why I would want to deploy something by pushing changes to the server. In my mental model the repo contains the SOT, and whatever’s running on the server is ephemeral, so I don’t want to mix those two things.

I guess it’s more comfortable than scp-ing individual files for a hotfix, but how does this beat pushing to the SOT, sshing into the server and pulling changes from there?

What are some fun/creative ways to do GitHub/GitLab style CI/CD with this method? Some kind of entry point script on push that determines what to do next? How could you decide some kind of variables like what the push was for?

I actually realized this last week, and have yet to try it. Programming for almost fifty years, using Git for thirteen years, and not an idiot (although there are those who would dispute this, including at times my spouse).

I never thought about it. If somebody had asked me, yeah. Of course it makes sense. But it's just one of those things where I haven't thought about possibility.

Filesystems and folders are foreign and elusive concepts to gen Z.

https://www.theverge.com/22684730/students-file-folder-direc...

I imagine larger part of the developer community does not, in fact, know that GitHub is not git and one can get everything they need without feeding their code to Microsoft's AI empire. Just another "Embrace, extend, and extinguish"

Or just put the repo in a shared directory in a high-trust group of developers (or just yourself).

Considering git is one of those things barely anyone knows how to actually use, yes

I was aware that it should be possible to interact directly with another repository on another machine (or, heck, in another directory on the same machine), which implies that ssh access is sufficient, but I was unaware of how that would be done.

There's definitely generational loss about the capabilities of git. In the beginning, git was a new version control option for people to explore, now git is the thing you learn to collaborate on github/lab/ea. I remember the Chagon book coming out as the peak between dense technical explainers and paint by numbers how-tos.

I would be surprised if more than 10% of git users know that. Would be equally surprised if more than 20% of git users know how to use ssh.

I think your age isn't the issue, but I suspect you're in a bubble.

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

DNS is in the same predicament. :-p

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.

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

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" :)

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

This is classic git usage. A "pull request" was literally just asking someone to pull from your branch. GitHub co-opted the term for their own thing.

The thing that people really don't seem to get these days is how your master branch is a different branch from someone else's master branch. So pulling from one master to another was a normal thing. When you clone you get a copy of all the branches. You can commit to your master branch all you want, it's yours to use however you want to.

Instead of excluding non-public directories, I like to make an explicit `public` directory (or `doc`, `doc-root`, whatever you want to call it). Then configure your server to point to that subdirectory and don’t worry about the repo.

I usually throw `etc` and `log` directories at the top level as well and out my server config in etc, and have a gitignite rule to ignore everything in logs, but it’s there and ready for painless deployment.

Since the web root is already a sub directory, more sensitive things can go into the same repo without worrying about exposing them.

I expose my .git directory to the public internet on purpose. If I don't, how will anyone else clone the repo?

But what, exactly, was pwned? Did you have secrets in the git repo?

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

A repo is as database containing a tree of commits. Then you got the concept of branch, which points to a specific commit. Then there's the special pointer HEAD which is the latest commit for the current worktree.

When you checkout (now switch) a branch, HEAD is now the same as the branch (they point to the same commit). When you do operation like commit, reset, reset,... both the head and the branch are updated. So if a remote node tries to update the local node via a push on its end, that would mess up the local worktree. So you create a bare repo instead which can't contain a local worktree.

Note: A worktree is computed from the initial commit to the commit currently identified by HEAD by following the parent information on each commit.

The staging area is like a stored snapshot of what you would like to commit. You can always create patch between HEAD and the worktree, edit it, and then save the patch as the commit, then apply the leftover to the worktree. The staging just make that easier. It's a WIP patch for the next commit.

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

Yeah, I am in the same boat. My files are either non-staged or committed about 99.99% of the time. For me the concept of staging is completely useless

you don't need to specify the protocol.

For file protocol, just type a path.

For ssh, type a ssh connection string like lion@myserver.test:path/to/file

That's because git is hard to use and full of commands which are making no sense. Eventually people will learn to just clone, pull, push and occasionally merge and be done with it.

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

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

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.

This is the first time I've heard of a Git client that's too broken to use HTTP dumb mode.

I feel like this is a bug that Xcode should fix

One of my favorite tools available for Linux is called gitolite. It's in the Debian repo.

https://gitolite.com/gitolite/

If you think the bare bones example is interesting and want something simple just for you or a small group of people, this is one step up. There's no web interface. The admin is a git repository that stores ssh public keys and a config file that defines repo names with an ACL. When you push, it updates the authorization and inits new repositories that you name.

I put everything in repos at home and a have multiple systems (because of VMs) so this cleaned things up for me considerably.

Could also consider running a Tangled knot (lightweight, headless git servers): https://tangled.org

I really like forgejo, but the git hosting bit is really just one feature for me. Their ci/cd runners, package repos and such are all things I need and forgejo includes in one nice bundle.

If I was just using it for git hosting I'd probably go for something more light weight to be honest.

A lot of people do host Forejo but unless you are actually working with other people and they need a reduction in access via pull requests it doesn't do much other than provide a pretty GUI to look at. The bare SSH approach makes more sense for personal projects.

am using gitea. but thinking of switching to serve (charm).

Forgejo is working okay for me.

Hard to justify using SSH for Git. Principle of least power and all that

Found a solution to this recently (this is not my blog): https://nathan.rs/posts/fixing-ios-codeblocks/

CSS needs some tweaking for iOS Safari, I guess.

Seen this a lot as well with Safari on the iPhone.

I use non-bare git because it's just transferring code between multiple machines for cross-platform locally run software; that is, it's just checkouts on mac, Windows, and Linux and commits being pushed amongst them. But then I also use worktrees and stuff, so maybe I'm weird.

Perhaps the only issue with this setup is that you lose some of the robustness of git: mess up one repo beoynd repair, and you've just messed up all the checkouts everywhere.

I sync my repos manually (using GitHub as the always-on remote, but I'm not particularly attached to it). This gives me more resilience should I blow up the repo completely (hard to do, I know).

Are basic git concepts like bare repos "obscure tribal knowledge" these days? What do you think ".git" directory is?

> I tried this and it is never as smooth as described.

I think your comment shows some confusion that it's either the result or cause of some negative experiences.

Starting with GitHub. The primary reason it "just works" is because GitHub, like any SaaS offering, is taking care of basic things like managing servers, authorization, access control, etc.

Obviously, if you have to setup your own ssh server, things won't be as streamlined as clicking a button.

But that's obviously not the point of this post.

The point is that the work you need to do to setup a Git server is way less than you might expect because you already have most of the things already set, and the ones that aren't are actually low-hanging fruit.

This should not come as a surprise. Git was designed as a distributed version control system. Being able to easily setup a stand-alone repository was a design goal. This blog post covers providing access through ssh, but you can also create repositories in any mount point of your file system, including in USB pens.

And, yes, "it just works".

> The official Git documentation for example has its own documentation that I failed to get work. (it is vastly different from what OP is suggesting)

I'm sorry, the inability to go through the how-to guide that you cited has nothing to do with Git. The guide only does three things: create a user account, setup ssh access to that account, and create a Git repository. If you fail to create a user account and setup ssh, your problems are not related to Git. If you created a user account and successfully setup ssh access, all that is missing is checking out the repo/adding a remote repo. If you struggle with this step, your issues are not related to Git.

The cool thing is that once you know how simple it is to self host (I certainly didn't know before, just used github), you learn a skill that you can apply to many different contexts, and understand better what actually goes on in systems you depend on. That's what these "tech should be invisible" people miss, where they tout that you should instead learn SASS solutions where you have zero ownership nor agency, instead of taking the time to learn transferable skills.

> obscure tribal knowledge

The knowledge is neither obscure nor tribal, it is public and accessible. And likely already on your system, in the form of man-pages shipped with your git binaries.

> The problem with software development is that not knowing such "tribal knowledge" is considered incompetence.

Consequently.

It is "incompetence," or at the very least, it is unwise.

At the very least, a huge part of the intent of Git's very design was decentralization; though as is the case with many good tools, people don't use them as they are designed.

Going further, simply because "deeply centralized Git" is very popular, does not AT ALL determine that "this is the better way to do things." Please don't frame it as if "popular equals ideal."

God forbid we learn how our tools work.

> Its because GitHub "Just Works".

IPv6 still doesn't work with GitHub: https://doesgithubhaveipv6yet.com/

People use github because it has a bunch of features outside git and because they don't already have a server.

Not because it's hard or obscure to put git on your server.

> Its because GitHub "Just Works".

Unfortunately (though expected), ever since Microsoft took over this has devolved into GitHub "sometimes works".

I understand where you're coming from, but this seems like a terrible defeatist attitude to have.

What are we supposed to do ... throw our hands up because GitHub won?

I'll be down voted, but I'll say it. If you hold that attitude and you don't learn the fundamentals, if you don't understand your tools, you're a bad developer and a poor craftsman. You're not someone I would hire or work with.

> Technology is best when it is invisible

For normal users. Having this tribal knowledge is basically what makes developer and it’s their job to make technology invisible for others. Someone has to be behind the curtain.

> Why is GitHub popular? its not because people are "dumb" as others think.

> Its because GitHub "Just Works".

Git also "just works". GitHub simply offers a higher level of abstraction, a graphical UI, and some value-add features on top of Git. How much better all this really is arguable. I would say that it's disastrous that most developers rely on a centralized service to use a distributed version control system. Nevermind the fact that the service is the single largest repository of open source software, owned and controlled by a giant corporation which has historically been hostile to OSS.

GitHub "won" because it came around at the right time, had "Git" in its name—which has been a perpetual cause of confusion w.r.t. its relation with Git—, and boosted by the success of Git itself largely due to the cult of personality around Linus Torvalds. Not because Git was technically superior, or because GitHub "just works".

> You don't need obscure tribal knowledge

As others have said, a bare repository is certainly not "tribal knowledge". Not anymore than knowing how to use basic Git features.

> Like the adge goes, "Technology is best when it is invisible"

Eh, all technology is an abstraction layer built on top of other technology. Whether it's "invisible" or not depends on the user, and their comfort level. I would argue that all abstractions also make users "dumber" when it comes to using the layers they abstract. Which is why people who only rely on GitHub lose the ability, or never learn, to use Git properly.