Absolutely. Every service you run, whether containerized or not, is software you have to upgrade, maintain, and back up. Containers don’t magically alleviate the need for basic software/service maintenance.
Yes, but doesn’t that also apply for a machine running bare git?
Not containers also adds some challenges with posibly having dependecies problems. I’d say running bare git is not a lot easier than having a container with say forgejo.
Right now I have a NAS. I have to upgrade and maintain my NAS. That’s table stakes already. But that alone is sufficient to use bare git repos.
If I add Gitea or whatever, I have to maintain my NAS, and a container running some additional software, and some sort of web proxy to access it. And in a disaster recovery scenario I’m now no longer just restoring some files on disk, I have to rebuild an entire service, restore it’s config and whatever backing store it uses, etc.
Even if you don’t already have a NAS, setting up a server with some storage running SSH is already necessary before you layer in an additional service like Gitea, whereas it’s all you need to store and interact with bare git repos. Put the other way, Gitea (for example) requires me to deploy all the things I need to host bare repos plus a bunch of addition complexity. It’s a strict (and non-trivial) superset.
I dont know. 😆 im really just trying to get it in case -for example- of needing to advice someone in such a case :) my confusion probably comes from the fact that I have never host anything outside containers.
I still see it a bit diferent. A well structured container structure with configs as files instead of bare commands, back up volumes would be the same effort… But who knows. Regarding the rest like proxies, well you do not really need one.
Honestly the issue here may be a lack of familiarity with how bare repos work? If that’s right, it could be worth experimenting with them if only to learn something new and fun, even if you never plan to use them. If anything it’s a good way to learn about git internals!
Anyway, apologies for the pissy coda at the end, I’ve deleted it as it was unnecessary. Keep on having fun!
Absolutely. Every service you run, whether containerized or not, is software you have to upgrade, maintain, and back up. Containers don’t magically alleviate the need for basic software/service maintenance.
Yes, but doesn’t that also apply for a machine running bare git?
Not containers also adds some challenges with posibly having dependecies problems. I’d say running bare git is not a lot easier than having a container with say forgejo.
No. It’s strictly more complexity.
Right now I have a NAS. I have to upgrade and maintain my NAS. That’s table stakes already. But that alone is sufficient to use bare git repos.
If I add Gitea or whatever, I have to maintain my NAS, and a container running some additional software, and some sort of web proxy to access it. And in a disaster recovery scenario I’m now no longer just restoring some files on disk, I have to rebuild an entire service, restore it’s config and whatever backing store it uses, etc.
Even if you don’t already have a NAS, setting up a server with some storage running SSH is already necessary before you layer in an additional service like Gitea, whereas it’s all you need to store and interact with bare git repos. Put the other way, Gitea (for example) requires me to deploy all the things I need to host bare repos plus a bunch of addition complexity. It’s a strict (and non-trivial) superset.
I dont know. 😆 im really just trying to get it in case -for example- of needing to advice someone in such a case :) my confusion probably comes from the fact that I have never host anything outside containers.
I still see it a bit diferent. A well structured container structure with configs as files instead of bare commands, back up volumes would be the same effort… But who knows. Regarding the rest like proxies, well you do not really need one.
Thanks taking the time to explain you point tho!
Honestly the issue here may be a lack of familiarity with how bare repos work? If that’s right, it could be worth experimenting with them if only to learn something new and fun, even if you never plan to use them. If anything it’s a good way to learn about git internals!
Anyway, apologies for the pissy coda at the end, I’ve deleted it as it was unnecessary. Keep on having fun!