Hello,
Set up a CentOS 7.5 VM linode for git now that github has been bought.
I'm not anti-microsoft but I'm worried they will make changes that I don't like (e.g. requiring ms account, changing billing, etc.) so I figured better take control now.
Currently moving my private repos and have them set up in my home directory there, but my public repos - I want to set them up with a web interface so people can browse them etc. and do a git clone w/o needing authentication.
I'll be putting those in /srv/git and using a different username than the account for my private git repositories.
But... can anyone recommend a web front end?
It doesn't need to be as fancy as github but it does need to parse markdown as all my documentation is in markdown.
Thanks for suggestions.
Preferably something that "just works" with CentOS 7.
-=-
What would be fantastic is if someone made some kind of federation type service similar to how Mastodon works that lets public git repositories that opt in be found without needing to be on a centralized server.
But I doubt that currently exists.
W dniu 06.06.2018 o 12:06, Alice Wonder pisze:
Set up a CentOS 7.5 VM linode for git now that github has been bought. I'm not anti-microsoft but I'm worried they will make changes that I don't like (e.g. requiring ms account, changing billing, etc.) so I figured better take control now. Currently moving my private repos and have them set up in my home directory there, but my public repos - I want to set them up with a web interface so people can browse them etc. and do a git clone w/o needing authentication. I'll be putting those in /srv/git and using a different username than the account for my private git repositories. But... can anyone recommend a web front end? It doesn't need to be as fancy as github but it does need to parse markdown as all my documentation is in markdown. Thanks for suggestions. Preferably something that "just works" with CentOS 7. -=- What would be fantastic is if someone made some kind of federation type service similar to how Mastodon works that lets public git repositories that opt in be found without needing to be on a centralized server.
But I doubt that currently exists.
Have you tried GitLab? I'm currently testing it, i thing it could be self-hosted. You also can try gitbucket, we are using it and works on CentOS7
On 06/06/18 12:06, Alice Wonder wrote:
Hello,
Set up a CentOS 7.5 VM linode for git now that github has been bought.
I'm not anti-microsoft but I'm worried they will make changes that I don't like (e.g. requiring ms account, changing billing, etc.) so I figured better take control now.
Currently moving my private repos and have them set up in my home directory there, but my public repos - I want to set them up with a web interface so people can browse them etc. and do a git clone w/o needing authentication.
I'll be putting those in /srv/git and using a different username than the account for my private git repositories.
But... can anyone recommend a web front end?
It doesn't need to be as fancy as github but it does need to parse markdown as all my documentation is in markdown.
Thanks for suggestions.
Preferably something that "just works" with CentOS 7.
Something light, that just works : https://gitea.io But it depends on your needs
The good news is that I started to use it for some infra git repositories for CentOS infra, so I had to build a rpm (and so wrote a .spec for that). I build those on CBS/koji and built pkgs are available directly there : https://cbs.centos.org/koji/packageinfo?packageID=6852
Cheers,
On 2018-06-06, Alice Wonder alice@domblogger.net wrote:
I'll be putting those in /srv/git and using a different username than the account for my private git repositories.
But... can anyone recommend a web front end?
Another recommendation for Gitlab. For maximum flexibility you can just run it out of a Docker container with appropriate volume mounts for persistent data.
--keith
On 06/06/2018 09:08 PM, Keith Keller wrote:
On 2018-06-06, Alice Wonder alice@domblogger.net wrote:
I'll be putting those in /srv/git and using a different username than the account for my private git repositories.
But... can anyone recommend a web front end?
Another recommendation for Gitlab. For maximum flexibility you can just run it out of a Docker container with appropriate volume mounts for persistent data.
--keith
I'm actually using something called GitList.
Simple and I like simple.
The 0.6 version had remote code execution bug so I do have to go through the code and make sure all proper validation is done, but what I want to do is simple and what GitList does is simple.
I don't like overly complex solutions even when there are installers that make it seem simple.
On Jun 6, 2018, at 4:06 AM, Alice Wonder alice@domblogger.net wrote:
I'm not anti-microsoft but I'm worried they will make changes that I don't like (e.g. requiring ms account, changing billing, etc.) so I figured better take control now.
What had you using GitHub in the first place, then? Is it just the web UI, since you’ve apparently decided that none of GitHub’s other major advantages over stock Git matter? Those being:
- pull request management - the social network - one-click hosting - issue tracking - GitHub.io
But... can anyone recommend a web front end?
Do you actually enjoy using Git over the alternatives? Do you know what your alternatives are?
Once you get past a perceived need to participate in the network effects from the popularity of Git and GitHub, you have several superior options, on some axes.
My personal choice is Fossil, the DVCS behind SQLite:
It’s much easier to use Fossil than Git when things go well, it’s less likely to get you tangled up than Git when things *don’t* go well, and it provides much of what GitHub does over stock Git.
There’s only one area I’m aware of where Git is actually easier to use than Fossil, and that’s in the initial clone. It’s a single command in Git, whereas it’s a several-step process in Fossil, in part owing to one of Fossil’s advantages over Git, that being that the local repository clone and local checkout are separate things in Fossil, which avoids the need for hacks like git-worktree.
If you’re worried that your users will have to deal with that complexity, it’s not true: Fossil makes it easy to set up single-click zip and tarball download links, so that those not needing a “real” repo checkout don’t have to put up with the complexity.
If you want to see it in action, the Fossil web site I pointed you to above *is* Fossil. (They eat their own dog food!) The SQLite web site is another: https://sqlite.org/
It doesn't need to be as fancy as github
Fossil’s web UI is more advanced than GitHub in some ways:
1. I find Fossil’s timeline view more useful than GitHub’s closest equivalent, the “Commits” page. The commits all look “flat” to me in GitHub, whereas parentage, branches, etc. are clearer in Fossil’s web timeline view. I suspect this is actually a reflection of a difference in the underlying philosophies of these two DVCSes rather than some UI designer’s idiosyncratic preference, but I’ll get back to that later.
2. Fossil makes it easy to diff two versions from the web UI: click the bubble next to the “from” version in the timeline view, then click the bubble next to the “to” version. GitHub’s equivalent is much more complicated:
https://help.github.com/articles/comparing-commits-across-time/
3. Fossil’s ticket tracker is more advanced than GitHub’s issue tracker in several ways, and it’s quite configurable if you don’t like the out-of-box behavior. GitHub’s issue tracker is little more than a tagged comment system.
4. Each Fossil instance can be configured to a custom startup page. By default, it’s a wiki document called “Home”, which you typically write to serve the needs of new users on a public project. For private projects, my first need on visiting the Fossil web UI is almost never a wiki document, so I find it more useful to default to the timeline view.
If you want a more GitHub-like experience, you could make the default web UI view be the Files page, but I never quite understood why I’d like to see a file browser as my project’s default presentation to the public. If you force me to dig through the Files view to find things in your project, the project’s maintainers have probably failed in their duty to guide new users to key material.
5. Fossil is skinnable. If you don’t like the default skin, which is that used by the Fossil and SQLite project sites, it currently ships with a dozen others, one of which you may like better. And if you don’t like any of those, anyone with web front-end skills can make a new one. Here’s a non-default skin that I made, to match the esthetics of the hardware related to the repository:
https://tangentsoft.com/pidp8i/
There must be advantages to GitHub’s web UI relative to Fossil, but none come immediately to my mind. I’ve asked GitHub fans to name some, and so far I’ve only gotten vague answers that amount to familiarity rather than objective advantages.
Now, above I spoke of a major philosophical difference between Git and Fossil: Git was made to support the needs of the Linux kernel developers, whereas Fossil was made to support the needs of the SQLite developers. Which one is closer to the way you manage your projects?
There are several differences between the two DVCSes that I believe fall out of that basic difference.
Git wants each “leaf” developer to work disconnected from the rest until he has something coherent to push up through the commit hierarchy towards the core. Thus “fork me on GitHub”, the private stash, rebase, etc. I believe this is also why GitHub’s commit view looks “flat:” the Git esthetic is that everything is made to appear as though it happened in a perfectly coordinated fashion even though the actual development process was an otherwise unmanageable mess.
You need these design choices when, like the Linux kernel, you have thousands of developers in hundreds of companies, plus innumerable singletons running around providing drive-by patches.
Fossil, by contrast, records what happens, as it happens, publicly. It’s better suited to the vast majority of projects, where the developers are expected to work closely together. Fossil is a coordination tool for coordinated teams, whereas Git is a coordination tool for herds of cats. :)
Again I ask, which project does yours most closely resemble from a development process standpoint: SQLite or the Linux kernel?
An outsider who didn’t understand the nature of network effects and didn’t watch the history happen might assume that the majority of developers believe they have Linus Torvalds’ problems, and thus also need a tool specifically crafted to meet his needs.
For those with existing Git repositories, Fossil has an import mechanism:
https://fossil-scm.org/index.html/doc/trunk/www/inout.wiki
…and an export mechanism if you later decide that you really do have Linus Torvalds’ same problems. :) Or more likely, that you really do need the benefit of the network effects.
but it does need to parse markdown as all my documentation is in markdown.
Fossil does that just fine. The dialect differs a bit from GitHub-flavored Markdown, but it’s quite usable.
Fossil also allows pure HTML and a wiki dialect.
Preferably something that "just works" with CentOS 7.
Fossil doesn’t seem to be packaged in any of the major CentOS repositories, but the official binary appears to run on CentOS 7:
https://fossil-scm.org/index.html/uv/download.html
I say “appears to” because I normally use binaries I build from source, since I frequently like to try out upcoming features and such. Fossil’s development trunk is generally quite stable without being moribund, which is a sign of a well-managed and healthy project.
On 06/07/18 14:18, Warren Young wrote:
On Jun 6, 2018, at 4:06 AM, Alice Wonder alice@domblogger.net wrote:
I'm not anti-microsoft but I'm worried they will make changes that I don't like (e.g. requiring ms account, changing billing, etc.) so I figured better take control now.
What had you using GitHub in the first place, then? Is it just the web UI, since you’ve apparently decided that none of GitHub’s other major advantages over stock Git matter? Those being:
- pull request management
- the social network
- one-click hosting
- issue tracking
- GitHub.io
But... can anyone recommend a web front end?
Do you actually enjoy using Git over the alternatives? Do you know what your alternatives are?
Once you get past a perceived need to participate in the network effects from the popularity of Git and GitHub, you have several superior options, on some axes.
My personal choice is Fossil, the DVCS behind SQLite:
https://fossil-scm.org/
Thank you, Warren, for nice writeup!! It's very instructive!
Valeri
It’s much easier to use Fossil than Git when things go well, it’s less likely to get you tangled up than Git when things *don’t* go well, and it provides much of what GitHub does over stock Git.
There’s only one area I’m aware of where Git is actually easier to use than Fossil, and that’s in the initial clone. It’s a single command in Git, whereas it’s a several-step process in Fossil, in part owing to one of Fossil’s advantages over Git, that being that the local repository clone and local checkout are separate things in Fossil, which avoids the need for hacks like git-worktree.
If you’re worried that your users will have to deal with that complexity, it’s not true: Fossil makes it easy to set up single-click zip and tarball download links, so that those not needing a “real” repo checkout don’t have to put up with the complexity.
If you want to see it in action, the Fossil web site I pointed you to above *is* Fossil. (They eat their own dog food!) The SQLite web site is another: https://sqlite.org/
It doesn't need to be as fancy as github
Fossil’s web UI is more advanced than GitHub in some ways:
I find Fossil’s timeline view more useful than GitHub’s closest equivalent, the “Commits” page. The commits all look “flat” to me in GitHub, whereas parentage, branches, etc. are clearer in Fossil’s web timeline view. I suspect this is actually a reflection of a difference in the underlying philosophies of these two DVCSes rather than some UI designer’s idiosyncratic preference, but I’ll get back to that later.
Fossil makes it easy to diff two versions from the web UI: click the bubble next to the “from” version in the timeline view, then click the bubble next to the “to” version. GitHub’s equivalent is much more complicated:
https://help.github.com/articles/comparing-commits-across-time/
Fossil’s ticket tracker is more advanced than GitHub’s issue tracker in several ways, and it’s quite configurable if you don’t like the out-of-box behavior. GitHub’s issue tracker is little more than a tagged comment system.
Each Fossil instance can be configured to a custom startup page. By default, it’s a wiki document called “Home”, which you typically write to serve the needs of new users on a public project. For private projects, my first need on visiting the Fossil web UI is almost never a wiki document, so I find it more useful to default to the timeline view.
If you want a more GitHub-like experience, you could make the default web UI view be the Files page, but I never quite understood why I’d like to see a file browser as my project’s default presentation to the public. If you force me to dig through the Files view to find things in your project, the project’s maintainers have probably failed in their duty to guide new users to key material.
Fossil is skinnable. If you don’t like the default skin, which is that used by the Fossil and SQLite project sites, it currently ships with a dozen others, one of which you may like better. And if you don’t like any of those, anyone with web front-end skills can make a new one. Here’s a non-default skin that I made, to match the esthetics of the hardware related to the repository:
There must be advantages to GitHub’s web UI relative to Fossil, but none come immediately to my mind. I’ve asked GitHub fans to name some, and so far I’ve only gotten vague answers that amount to familiarity rather than objective advantages.
Now, above I spoke of a major philosophical difference between Git and Fossil: Git was made to support the needs of the Linux kernel developers, whereas Fossil was made to support the needs of the SQLite developers. Which one is closer to the way you manage your projects?
There are several differences between the two DVCSes that I believe fall out of that basic difference.
Git wants each “leaf” developer to work disconnected from the rest until he has something coherent to push up through the commit hierarchy towards the core. Thus “fork me on GitHub”, the private stash, rebase, etc. I believe this is also why GitHub’s commit view looks “flat:” the Git esthetic is that everything is made to appear as though it happened in a perfectly coordinated fashion even though the actual development process was an otherwise unmanageable mess.
You need these design choices when, like the Linux kernel, you have thousands of developers in hundreds of companies, plus innumerable singletons running around providing drive-by patches.
Fossil, by contrast, records what happens, as it happens, publicly. It’s better suited to the vast majority of projects, where the developers are expected to work closely together. Fossil is a coordination tool for coordinated teams, whereas Git is a coordination tool for herds of cats. :)
Again I ask, which project does yours most closely resemble from a development process standpoint: SQLite or the Linux kernel?
An outsider who didn’t understand the nature of network effects and didn’t watch the history happen might assume that the majority of developers believe they have Linus Torvalds’ problems, and thus also need a tool specifically crafted to meet his needs.
For those with existing Git repositories, Fossil has an import mechanism:
https://fossil-scm.org/index.html/doc/trunk/www/inout.wiki…and an export mechanism if you later decide that you really do have Linus Torvalds’ same problems. :) Or more likely, that you really do need the benefit of the network effects.
but it does need to parse markdown as all my documentation is in markdown.
Fossil does that just fine. The dialect differs a bit from GitHub-flavored Markdown, but it’s quite usable.
Fossil also allows pure HTML and a wiki dialect.
Preferably something that "just works" with CentOS 7.
Fossil doesn’t seem to be packaged in any of the major CentOS repositories, but the official binary appears to run on CentOS 7:
https://fossil-scm.org/index.html/uv/download.htmlI say “appears to” because I normally use binaries I build from source, since I frequently like to try out upcoming features and such. Fossil’s development trunk is generally quite stable without being moribund, which is a sign of a well-managed and healthy project. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Alice Wonder -
Fabian Arrotin -
Keith Keller -
Marcin Trendota -
rainer＠ultra-secure.de -
Valeri Galtsev -
Warren Young