It's obvious as soon as you consider that your push will overwrite a ref that's currently checked out in the target's repo workdir. The exact same thing happens when pushing to local repos. You don't have to make a repo bare to avoid this issue, but it's certainly the easiest way to avoid it altogether when you don't need a workdir on the server side.
It's obvious that it needs to update the ref. It's not obvious that this would cause any problems. You could fix HEAD as part of writing the ref. Automatically managing HEAD is normal git behavior.
It's obvious that something non-obvious would have to happen with the workdir behind the user's back. Imagine that you are working with your workdir while someone else pushes something to your repo. Bailing out is the only sane option (unless something else has been explicitly requested by the user).
...except of all the things that rely on the HEAD pointing to another ref now changing their behavior. gbp will by default bail off if HEAD is not on a branch, "git commit" won't update the ref you thought it will cause you're now suddenly on "detached HEAD" etc.
I've never heard of... debian package builder? I don't care if it gets annoyed; if that's one of the biggest issues then that's a good sign for the method.
Yes the commit won't be on the branch you want, but you'd get about the same issue if the two repos had a bare upstream. The branch diverges and you need to merge. It's a bit less ergonomic here but could be improved. Git could use branch following improvements in general.
> Yes the commit won't be on the branch you want, but you'd get about the same issue if the two repos had a bare upstream.
Not at all. The commit would have "landed" on the exact branch you thought it will. How it will be reconciled with a diverged remote branch is completely orthogonal and may not even be of concern in some use cases at all.
The situation is almost identical except you don't have a cute name for your new commit. Let's say you add a ref to your detached commit, perhaps local/foo. Then you're looking at a divergence between foo and local/foo. If you had a bare upstream it would be a divergence between origin/foo and foo. No real difference. And if you don't want to reconcile then you don't have to.
If git was a tiny bit smarter it could remember you were working on "foo" even after the ref changes.
Of course it could, but that doesn't yet mean it should. A checked-out ref is considered to be in-use and not to be manipulated (unless done in tandem with HEAD), not just by "git push" but also other tools like "git branch". It's consistent and, IMO, less surprising than what you propose. It could be an optional behavior configured by receive.denyCurrentBranch, though I don't see a good use-case for it that isn't already handled by updateInstead.
If you use "git branch -d" you should expect the ref to be deleted, and yet:
> error: cannot delete branch 'main' used by worktree at '/tmp/git'
You could build the system differently and what seems like a sane default would be different there, but it would be a different system. In this system, HEAD isn't being manipulated by things not meant to manipulate it.
Yeah this is the best arguments for GitHub type of web git GUI. Not knowing bare repo seems just like a devs not reading docs. And I'm sorry in this day and age devs needs to keep up and just type git like curl http://...../install.sh type of thing.
However would NEVER trust Github since the MS acquisition. codeberg and https://forgejo.org are perfectly sound FOSS alternative to GitHub and GigLabs nowdays.
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.
The vast majority [0] of developers working with git daily have no mental model of git repos and just do a mental equivalent of copy'n'pasting commands and it's enough to let them do their work (until something breaks at least), so it doesn't seem like a particularly good indicator of whether something is obscure or not. There are many obscure things hiding in git, bare repos aren't one of those :)
> 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.
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.
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.
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."
> 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.
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.
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.
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-...