You already have a Git server

https://maurycyz.com/misc/easy_git/

by chmaynard • 9 months ago

653 426 9 months ago

maurycyz.com

thyristan• 9 months ago

Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?

liveoneggs6• 9 months ago

most people think git = github

halJordan• 9 months ago

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"

albert_e• 9 months ago

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.

bfkwlfkjf6• 9 months ago

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.

setopt• 9 months ago

Yup. I’ve heard several people say that Git is a product from Microsoft…

ruguo• 9 months ago

Looks like they’re not developers after all

brucehoult• 9 months ago

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

ryandv• 9 months ago

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

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

liveoneggs6• 9 months ago

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

andai2• 9 months ago

It gets better than that...

https://www.youtube.com/shorts/D1dv39-ekBM

politelemon• 9 months ago

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

superdisk2• 9 months ago

If you do it over NFS or whatever then you can collaborate as well.

torben-friis2• 9 months ago

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?

skydhash10• 9 months ago

There's a lot of configuration possible due to the fact that git is decentralized. I have a copy on my computer which is where I do work. Another on a vps for backup. Then one on the app server which only tracks the `prod` branch. The latter is actually bare, but there's a worktree for the app itself. The worktree is updated via a post-receive hook and I deploy change via a simple `git push server prod`

t_mahmood2• 9 months ago

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.

crazygringo3• 9 months ago

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.

candiddevmike• 9 months ago

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?

yule• 9 months ago

I wrote about that idea here: https://www.stchris.net/tiny-ci-system.html

skydhash10• 9 months ago

`man 5 githooks` is your friend. Hooks are just scripts and they can receive parameters. `post-receive` is most likely what you would want.

CGamesPlay2• 9 months ago

Check the docs for the post-receive hook, it does give everything you need. I don't know what you have in mind by "GitHub/Gitlab style", but it's just a shell script, and you can add in as much yaml as you want to feel good about it.

I did a quick search for "post-receive hook ci" and found this one: https://gist.github.com/nonbeing/f3441c96d8577a734fa240039b7...

bluedino• 9 months ago

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

seba_dos120• 9 months ago

My theory is that git is just so easy to use without understanding it that you end up with lots of people using it without understanding it :)

isodev• 9 months ago

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"

tuwtuwtuwtuw• 9 months ago

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.

kleiba• 9 months ago

The non-Windows bubble?

dtgriscom• 9 months ago

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

__MatrixMan__3• 9 months ago

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.

skydhash10• 9 months ago

The Pro Git book is available online for free

https://git-scm.com/book/en/v2

tianqi• 9 months ago

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.

haskellshill4• 9 months ago

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.

kragen31• 9 months ago

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• 9 months ago

This is also vim

thwarted5• 9 months ago

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.

fingerlocks4• 9 months ago

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”

mewpmewp29• 9 months ago

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.

victorbjorklund• 9 months ago

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.

mewpmewp29• 9 months ago

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• 9 months ago

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

dogleash• 9 months ago

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.

thaumasiotes• 9 months ago

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.

nmz• 9 months ago

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.

paradox460• 9 months ago

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

tom_• 9 months ago

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.

djoanwnn• 9 months ago

It usually is. Normally you don't put a full shell behind ssh if you only expose git, but of cause you can

al_borland2• 9 months ago

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.

UK-Al05• 9 months ago

With cors this can be awkward now.

delta2uk• 9 months ago

I think if you're too young to know the earlier alternatives it's easy to overlook the distributed nature of git which made it different from them.

nicce4• 9 months ago

Interesting. I am just trying to decide between self-hosting Forgejo and other options for hosting Git in own private network.

omani2• 9 months ago

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

sesm• 9 months ago

I'm also using gitea, running on RPI5. Setup took like 15 mins, highly recommend.

icy3• 9 months ago

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

rustman123• 9 months ago

Does this support private repositories with collaboration?

nicce4• 9 months ago

That looks definitely interesting!

01HNNWZ0MV43FF• 9 months ago

Forgejo is working okay for me.

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

skydhash10• 9 months ago

Git is distributed, so there's no least power and all that. Everyone has full power over their own copy. What you want is one copy being the source of truth. You can always use HTTP for read-only access to that copy with a limited set of people having write access to update the copy. Patches can be shared via anything (git has built-in support for email).

orblivion• 9 months ago

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.

deltarholamda• 9 months ago

gitolite is great. It's simple and extremely lightweight.

PaulKeeble• 9 months ago

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.

bluehatbrit• 9 months ago

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.

singpolyma32• 9 months ago

One note, xcode and maybe some other clients can't use http "dumb mode". Smart mode is not hard to set up, but it's a few lines of server config more than this hook.

TIL about the update options for checked out branch. In practise though usually you want just the .git "bare" folder on server

saagarjha• 9 months ago

I feel like this is a bug that Xcode should fix

eptcyka• 9 months ago

There are many bugs Xcode should fix.

kragen31• 9 months ago

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

imiric2• 9 months ago

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

You might also want to restrict its directory and command access in the sshd config for extra security.

Then, when you need to create a new repository you run:

  sudo -u git git init --bare --initial-branch=main /home/git/myrepo.git

And use it like so:

  git clone git@myserver:myrepo.git

Or:

  git remote add myserver git@myserver:myrepo.git
  git push -u myserver main

This has the exact same UX as any code forge.

I think that initializing a bare repository avoids the workarounds for pushing to a currently checked out branch.

general14654• 9 months ago

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.

amelius• 9 months ago

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

matrss3• 9 months ago

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.

seba_dos120• 9 months ago

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• 9 months ago

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.

liveoneggs6• 9 months ago

yeah it seems odd that they don't just have remote> $HOME/repos/foo.git and then clone from there locally and remotely

kragen31• 9 months ago

See https://news.ycombinator.com/item?id=45713074 for a worked example of how it works with a bare repo.

ninkendo• 9 months ago

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

And it didn’t work. You have to ssh to the remote server and “git init” on a path first. How uncivilized.

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_dos120• 9 months ago

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

1oooqooq• 9 months ago

this article is very bad advice. this way things are extremely brittle and there's a reason all those settings are disabled by default. you will lose data, save from very specific use cases

the vastly superior way is 'git bare' which is a first class supported command without hacky settings.

ezst4• 9 months ago

As a git user "not by choice" (my preference going for mercurial every single day), I never understood why git needs this distinction between bare/non-bare (or commit vs staging for that matter). Seems like yet another leaky abstraction/bad design choice.

skydhash10• 9 months ago

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.

seba_dos120• 9 months ago

When you checkout (now switch) a branch, HEAD is now the same as the branch (they point to the same commit).

Actually, HEAD now points to that branch, which in turn points to the commit. It's a different state than when HEAD points directly to the same commit (called "detached HEAD" in Git's terminology) where this issue doesn't happen as you're not on a branch at all. It's a subtle, but important distinction when trying to understand what happens under the hood there.

DrinkyBird• 9 months ago

Mercurial has no distinction between a bare repo and a non-bare repo: any repo can have a working copy or not. You can check out a working copy with `hg update somerevision`, or get rid of it with `hg update null`.

You can push to a repo with a working copy, if you like; nothing will happen to that working copy unless you run `hg update`. Since you don’t need a working copy on the server’s repo, you never run `hg update` on it, and it’s effectively what git calls a bare repository.

ezst4• 9 months ago

So, exactly as DrinkyBird said: I still don't see a good reason for this distinction to exist, what's in the repo's history and in its working directory are orthogonal concepts that are tied together by a bad UX for no apparent gain.

rester324• 9 months ago

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

mbork_pl• 9 months ago

Staging is immensely useful in more than one case.

Case one: WiP on a branch, code is pretty stable, but I want to do some experiments which will likely be deleted. I stage everything and then make (unstaged) changes which I can then undo with two keystrokes.

Case two: I'm reviewing a complex PR, so I first merge it with --no-commit, then unstage everything and then stage chunks (or even individual lines) I have already reviewed.

Case three: I was coding in the state of flow and now I have a lot of changes I want to commit, but I want to separate them into several atomic commits. I stage the first batch of changes, commit, then stage another, commit, etc.

There are probably more, but these three alone are worth having the staging area.

ezst4• 9 months ago

Though I wasn't trying to say that there is no need for staging-based workflows, I was just saying that there is nothing in terms of convenience or capabilities that the staging area does that can't be achieved with just regular commits and amending/rewriting.

The immediate response from many git users when confronted to alternative VCSes is "well, it doesn't have a staging area, so it's obviously inferior" instead of going with "let's see how differently they approach this problem, and perhaps I will like it/git isn't all perfect after all".

mamcx• 9 months ago

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

bitbasher4• 9 months ago

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.

LambdaComplex• 9 months ago

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

zyxin• 9 months ago

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

bitbasher4• 9 months ago

I imagine the interviewer was one of those senior developers that still thinks git == github.

max_2• 9 months ago

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

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

Its because GitHub "Just Works".

You don't need obscure tribal knowledge like seba_dos1 suggests [0] or this comment https://news.ycombinator.com/item?id=45711294

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)

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

People don't need to deal with obscure error messages which is why they choose GitHub & why Github won.

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

[0] https://news.ycombinator.com/item?id=45711236

[1] https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-...

seba_dos120• 9 months ago

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

max_2• 9 months ago

Having to make a repo bare to not have issues with branches is definitely obscure.

have_faith• 9 months ago

The vast majority of developers working with git daily don’t know what a bare repo is, or that it exists at all. It’s not obscure knowledge as such, it’s just never come up for them as something they need.

general14654• 9 months ago

Now try to add a submodule X (which is a bare repository) to your repository Y

Good job, now you can't add it nor remove it, without manually removing it in .git folder.

myaccountonhn• 9 months ago

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.

blueflow3• 9 months ago

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.

croes• 9 months ago

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.

vaylian• 9 months ago

Its because GitHub "Just Works".

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

Dylan168078• 9 months ago

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.

motorest• 9 months ago

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.

bitbasher4• 9 months ago

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.

Tomis02• 9 months ago

git is not "the fundamentals". It's a tool that's very difficult to learn but we are forced to use because "it won" at some point.

Git's difficulty is NOT intrinsic; it could be a much better tool if Torvalds were better at UX. In short, I don't blame people who don't want to "learn git". They shouldn't have to learn it anymore than one learns to use a browser or Google docs.

imiric2• 9 months ago

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.

herpdyderp• 9 months ago

Its because GitHub "Just Works".

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

throwaway106382• 9 months ago

God forbid we learn how our tools work.

jrm44• 9 months ago

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

johnisgood2• 9 months ago

I am surprised how little software engineers (even those that use) know about git.

general14654• 9 months ago

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.

skydhash10• 9 months ago

Most people would just use `app` `app (final)`, `app (final 2)`, etc... VCS exists for a reason and I strongly believe that the intersection of people that say git is hard and people that do not know why you want a VCS is nearly a perfect circle.

jonhohle6• 9 months ago

People said the same thing about “advanced” operations with cvs and svn (and just called their admin for p4 or source safe). But I really don’t understand the sentiment.

Managing code is one of the cornerstones of software engineering. It would be like refusing to learn how to use a screwdriver because someone really just wants to hammer things together.

The great thing about $your-favorite-scm is that it transcends language or framework choices and is fungible for early any project, even outside of software. I’m surprised it isn’t part of more professional tools.

timmg• 9 months ago

There was a brief period when Google Cloud had support for hosting git on a pay-per-use basis. (I think it was called Google Cloud Repositories.) It had a clunky but usable UI.

I really preferred the idea of just paying for what I used -- rather than being on a "freemium" model with GitHub.

But -- as many things with Google -- it was shutdown. Probably because most other people do prefer the freemium model.

I wonder if this kind of thing will come back in style someday, or if we are stuck with freemium/pro "tiers" for everything.

XorNot2• 9 months ago

My git "server" is a folder of bare git repositories in home directory which I share with Syncthing.

It'd be great if there was more specific support. But in practice? No problems so far.

tasuki4• 9 months ago

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

XorNot2• 9 months ago

They're not checked out repos. They're bare repos, which I then checkout from.

The benefit is that git repos are essentially append only in this mode.

The folder itself is scheduled into an encrypted backblaze backup too.

eqvinox2• 9 months ago

  git clone ssh://username@hostname/path/to/repo

this is equivalent to:

  git clone username@hostname:path/to/repo

and if your usernames match between local and remote:

  git clone hostname:path/to/repo

(if the path has no leading /, it is relative to your home directory on the remote)

DrNefario• 9 months ago

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• 9 months ago

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.

eqvinox2• 9 months ago

You might want to read the documentation on "git remote". You can pull/fetch and push between repos quite arbitrarily, with plain ssh.

blueflow3• 9 months ago

Docs:

https://git-scm.com/docs/git-clone#_git_urls

https://git-scm.com/docs/git-init

globular-toast3• 9 months ago

The proper way to do this to make a "bare" clone on the server (a clone without a checked out branch). I was doing this in 2010 before I even signed up to GitHub.

jonhohle6• 9 months ago

I feel like something was lost along the way.

    git init —-bare

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:

    [remote “my-server”]
    url = ssh+git://…/deploy/path.git
    fetch = +refs/heads/*:refs/remotes/my-server
    push = +refs/heads/*:refs/remotes/my-laptop

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.

Sharlin2• 9 months ago

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.

webstrand5• 9 months ago

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.

jonhohle6• 9 months ago

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.

JamesLeonis• 9 months ago

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.

webstrand5• 9 months ago

    git clone --mirror <remote>

is another good one to know, it also makes a bare repository that is an exact clone (including all branches, tags, notes, etc) of a remote repo. Unlike a normal clone that is set up for local tracking branches of the remote.

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

Cheer2171• 9 months ago

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?

BatteryMountain4• 9 months ago

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!

kawsper• 9 months ago

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.

masklinn4• 9 months ago

How is it less confusing when your fork is also on github?

tobylane• 9 months ago

If I clone my fork, I always add the upstream remote straight away. Origin and Upstream could each be github, ambiguous.

pwdisswordfishy• 9 months ago

GitHub could not name it so, because it's not up to GitHub to choose.

mckn1ght3• 9 months ago

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

mzajc• 9 months ago

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

mckn1ght3• 9 months ago

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.

ompogUe• 9 months ago

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

eru• 9 months ago

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

imron• 9 months ago

GitHub is full of git anti-patterns

lloeki2• 9 months ago

“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 somehow the dead simple simplicity has trumped the lack of push ability

xk32• 9 months ago

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

tangotaylor2• 9 months ago

Beware of using this to publish static sites: you can accidentally expose your .git directory to the public internet.

I got pwned this way before (by a pentester fortunately). I had to configure Apache to block the .git directory.

jonhohle6• 9 months ago

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.

wizzwizz4• 9 months ago

Storing volatile data (e.g. logs) in the git-managed directory is an excellent way to lose all your data. https://fediverse.blog/~/Prismo/on-prismo-data-loss

cesnja• 9 months ago

You can still get hit by a path traversal exploit. The safest option is to only have the public files on the server.

CGamesPlay2• 9 months ago

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

tasuki4• 9 months ago

I expose the .git directories on my web server and never considered it a problem. I also expose them on GitHub and didn't consider that a problem either...

tangotaylor2• 9 months ago

No secrets like auth credentials or tokens but:

- Deleted files and development artifacts that were never meant to go public.

- My name and email address.

- Cringy commit messages.

I assumed these commits and their metadata would be private.

It was embarrassing. I was in high school, I was a noob.

kragen31• 9 months ago

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

binary132• 9 months ago

This is definitely nice but it doesn’t really support the full range of features of Git, because for example submodules cannot be local references. It’s really just easier to set up gitolite and use that in almost the same exact way but it’s much better.

mberning• 9 months ago

I do something similar. I create a bare repo on my dropbox folder or nas mount. Then checkout from bare repo file path to some place where I will be doing all the work.

prmph• 9 months ago

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.

jrm44• 9 months ago

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.

morshu90013• 9 months ago

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.

ashton314• 9 months ago

Git was explicitly designed to be decentralized.

jrm44• 9 months ago

It's not a "CLI" and yes, "decentralized" was literally one of the points of it.

semanticc• 9 months ago

Linux is not developed in GitHub.

kragen31• 9 months ago

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.

pixelmonkey• 9 months ago

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

jrm44• 9 months ago

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.

m3047• 9 months ago

DNS is in the same predicament. :-p

unethical_ban• 9 months ago

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.

ziofill• 9 months ago

What is it with code on blog posts where fonts have uneven size and/or font types (e.g. italics mixed in with regular)? I see this from time to time and I wonder if it’s intentional.

stabbles• 9 months ago

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

jcgl• 9 months ago

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.

patal3• 9 months ago

How would I sync access, if more than one people ssh-pushes onto the git repo? I assume syncing be necessary.

tasuki4• 9 months ago

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

patal3• 9 months ago

Sure, if they push one after the other. If they push at the same time however, does Git handle the sync on its own?

kragen31• 9 months ago

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

You can of course also run a local site generator here as well, although for dev3 I took a lighter-weight approach — I just checked in the HEADER.html file that Apache FancyIndexing defaults to including above the file directory listing and tweaked some content-types in the .htaccess file.

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.

kragen31• 9 months ago

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

3eb7988a1663• 9 months ago

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.

PantaloonFlames• 9 months ago

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

..in that order.

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?

kragen31• 9 months ago

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.

tonymet5• 9 months ago

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.

dlisboa2• 9 months ago

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.

tonymet5• 9 months ago

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

tonymet5• 9 months ago

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.

joeyguerra• 9 months ago

There’s also git daemon.

simonw3• 9 months ago

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.

nicce4• 9 months ago

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.

simonw3• 9 months ago

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.

iwontberude• 9 months ago

“By default, git won’t let you push to the branch that is currently checked out”

TIL that people use non-bare git.

mook• 9 months ago

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.

donatj• 9 months ago

Back when I started at my current job... 15 years ago... We had no central git server. No PR workflow. We just git pull-ed from each others machines. It worked better than you would expect.

We then went to using a central bare repo on a shared server, to hosted gitlab(? I think - it was Ruby and broke constantly) eventually landing on GitHub

globular-toast3• 9 months ago

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.

kragen31• 9 months ago

On GitHub, too, a "pull request" is literally just asking someone to pull from your branch.

cycomanic• 9 months ago

I suspect many who always use git remotely don't know that you can easily work with local repositories as well using the file protocol, git clone file:///path/to/repository will create a clone of the repository at the path.

I used that all the time when I had to move private repositories back and forth from work, without ssh access.

lionkor3• 9 months ago

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

whirlwin• 9 months ago

This is how Heroku has been doing it for years since it started out 10+ years ago.

$ git push heroku master

So you'll have to make sure to push to e.g. GitHub as well for version control.

gwd• 9 months ago

Git post-update hooks to do deployment FTW. I looked into the whole push-to-github to kick off CI and deployment; but someone mentioned the idea of pushing over ssh to a repo on your server and having a post-update hook do the deployment, and that turned out to be much simpler.

quasarj• 9 months ago

This is, in fact, what git was made for

hk1337• 9 months ago

You could just put a bare repo on a usb drive and pass it around but I wouldn’t recommend it.

ctm92• 9 months ago

you don't even need ssh, you can also just store the remote on a local or remote file system

Froztnova• 9 months ago

Huh, y'know I shouldn't be surprised that this is possible given what I know about ssh and git. Yet I am.

OhMeadhbh• 9 months ago

Yup. I do something similar: HTTPS://BI6.US/GI/B

TZubiri• 9 months ago

Hmm. I typically have:

- a prod server ( and a test server) with a git repo.

- a local machine with the git repo.

- a git server where code officially lives, nowadays just a github.

If I were to simplify and run my own git server of the third kind, I would probably not run a server for the sole purpose of hosting code, it would most likely run on the prod/test server.

So essentially I would be eliminating one node and simplifying. I don't know, maybe there's merits to having an official place for code to be in. Even if just semantics.

I know you can also use branches to have a "master" branch with code and then have migrations just be merging from master into a prod branch, but then again, I could have just master branches, but if it's on the test server then it's the test branch.

I don't know if spendint time reinventing git workflows is a very efficient use of brain juice though.

m463• 9 months ago

You can do it with just directories too.

  mkdir -p repo/project
  cd repo/project
  git init --bare

  cd ../..
  git clone repo/project
  cd project
  (do git stuff)

mmaaz• 9 months ago

Some time ago, I was on a team of researchers collaborating with a hospital to build some ML models for them. I joined the project somewhat late. There was a big fuss over the fact that the hospital servers were not connected to the internet, so the researchers couldn't use GitHub, so they had been stalled for months. I told them that before GitHub there was `git`, and it is already on the servers... I "set up" a git system for them.

AoifeMurphy• 9 months ago

Self hosting Git isn’t just geek freedom, it’s a mindset of redundancy. I’ve had repos vanish due to platform bans that’s when it really hit me that “distributed” isn’t just a design, it’s a reminder of responsibility.

BatteryMountain4• 9 months ago

In interviews, I've literally asked senior devops engineers and senior software engineers if they have hosted their own git servers and how to initialise one and not a single one has mentioned git init --bare..... which is disconcerting. They can deploy appliances (like gitlab, gitea) and build pipelines just fine, but none of them realized how git actually works underneath and how simple it all is.

catmanjan2• 9 months ago

Why is that disconcerting? There's simply too much software to be familiar with obscure features like this

Cthulhu_• 9 months ago

In a sense it's anything but obscure, that is, it's one of the most basic of features of the tool and the first thing (well, git init anyway) anyone ever uses.

But that's why people don't know about it, because they skip past the basics because in practice you never use it or need to know about it.

This is the reality of software engineering and the like though - mostly you learn what you need to know, because learning everything is usually wasteful and never used, and there's a lot available.

(I haven't been able to read documentation or a software book end to end in 20 years)

JackMorgan• 9 months ago

Because too many bad interviews are all about ensuring that the candidate knows the exact same 1% of CS/SWE knowledge as the interviewer.

Don't worry, karma dictates when the interviewer goes looking they'll get rejected for not knowing some similarly esoteric graph theory equation or the internal workings of a NIC card.

Too much of our interviewing is reading the interviewer's mind or already knowing the answer to a trick question.

The field is way too vast for anyone to even know a majority, and realistically it's extremely difficult to assess if someone is an expert in a different 1%.

Sometimes I feel like we need a system for just paying folks to see if they can do the job. Or an actually trusted credentialing system where folks can show what they've earned with badges and such.

A better interview question about this subject doesn't assume they have it memorized, but if they can find the answer in a short time with the internet or get paralyzed and give up. It's a very important skill to be able to recognize you are missing information and researching it on the Internet.

For example, one of my most talented engineers didn't really know that much about CS/SWE. However, he had some very talented buddies on a big discord server who could help him figure out anything. I kid you not, this kid with no degree and no experience other than making a small hobby video game would regularly tackle the most challenging projects we had. He'd just ask his buddies when he got stuck and they'd point him to the right blog posts and books. It was like he had a real life TRRPG Contacts stat. He was that hungry and smart enough to listen to his buddies, and then actually clever enough to learn on the job to figure it out. He got done more in a week than the next three engineers of his cohort combined (and this was before LLMs).

So maybe what we should test isn't data stored in the brain but ability to solve a problem given internet access.

BatteryMountain4• 9 months ago

Because the same kind of guys have one global ssh key they use for all server & all environments... they don't realise they can (and should) have multiple keys on one machine / one user. Different keys for different purposes.

Same issues with git: they don't realise they can have multiple configs, multiple remotes, etc. Never mind knowing how to sign commits.........

They claim to be linux boffins but cannot initialise a git repo. This has nothing to do with elitism. This is basic stuff.

What's next, they don't know what a bootloader or a partition is? Or run database engine with default settings? Or install a server OS and never bother to look at firewall config?

I'm truly not trying to be cruel.

isolay• 9 months ago

I wonder what's the missing link between this manual setup and something like gitea. Is gitea just automation of this?

lukasnxyz• 9 months ago

I do this for blog posts, but for server side work I just rsync my dir, much easier

sam_lowry_• 9 months ago

It's slightly more complicated to host your own git server on a generic linux box, because of file permissions.

I wrote a HOWTO a few weeks ago: http://mikhailian.mova.org/node/305

cncjchsue7• 9 months ago

git push prod

Until you have more users than dollars that's all you need.

brendyn• 9 months ago

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 just sitting around hacking away on our keyboards wanting to share what we've come up with every few minutes or so. I still have no idea how I would solve this. Maybe I'd just try coding with a syncthing directory shared between us, but then that's totally giving up on git

ekzy• 9 months ago

Have you tried git daemon? https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon

OkayPhysicist• 9 months ago

If you put a git repository in a shared drive via git clone --bare (makes it not checkout a branch, and doesn't setup any origin type stuff), you can use that as a remote, pushing/pulling etc. Setting up a network available shared drive on one of the two computers shouldn't be too difficult, and by git's distributed nature it's not exactly the end of the world if access temporary.

Another option would be to use the email-based workflow, but that's quite different from most people's expected git experience.

xk32• 9 months ago

I think if you just setup SSH a certain way you can then use git or sftp for access:

        Match User gituser
            ChrootDirectory /srv/git_chroot
            ForceCommand internal-sftp
            AllowTcpForwarding no
            X11Forwarding no
            PermitTTY no

But tbh sending patches is fun and easy! After you force yourself to do it a few times you might even prefer it to push/pull

pabs3• 9 months ago

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/

JimmaDaRustla• 9 months ago

Git is not a client/server architecture

shravani_05_01• 9 months ago

I have instagram id hack please

okoddcat• 9 months ago

Another alternative Open Source Git hosting tool https://github.com/gisiahq/gisia

You already have a Git server

Related Stories