On Jun 6, 2018, at 4:06 AM, Alice Wonder <alice@xxxxxxxxxxxxxx> 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/
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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
