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.
You already have a Git server
71–80 of 454 posts
Re: You already have a Git server
#72Earlier quoted context omitted.
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).
Re: You already have a Git server
#73I 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…
> 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.
Re: You already have a Git server
#74Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?
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?
`man 5 githooks` is your friend. Hooks are just scripts and they can receive parameters. `post-receive` is most likely what you would want.
Re: You already have a Git server
#75Just make the repository on the server side bare and you won't have to worry about checked out branches or renaming ".git" directory.
> 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.
Re: You already have a Git server
#76Earlier quoted context omitted.
most people think git = github
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 did…
What makes you say that people complain about the spread of incorrect knowledge "instead" of teaching? Because there's nothing wrong with doing both.
Re: You already have a Git server
#77I 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…
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.
Re: You already have a Git server
#78Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?
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?
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...
Re: You already have a Git server
#79Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?
Also relatively unknown: You can clone from a directory. It won't accomplish the backup feature but it's another option/feature.
If you do it over NFS or whatever then you can collaborate as well.
Re: You already have a Git server
#80Earlier quoted context omitted.
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).
Nothing has to happen to the workdir if you fix HEAD.