4 ms·

> I keep meaning to dig into Fossil, but I have no faith I could convince a team to use it. Developer or Fossil and SQLite here: I agree. In my experience, y

by SQLite 9y ago

> I keep meaning to dig into Fossil, but I have no faith I could convince a team to use it. Developer or Fossil and SQLite here: I agree. In my experience, you'd have better luck convincing the team to switch from vi to emacs. For all its many and well-documented faults, the Git/GitHub paradigm is what people want to use because it is what they are familiar with. All the same, I intend to keep right on using Fossil, thank you very much! So here is the idea I've been thinking of lately: What if Fossil were ported or enhanced to use Git's low-level file-formats so that unmodified git clients could seamlessly push and pull against the (enhanced) Fossil server. Call the new system "Fit" (Fossil+Git). Using Fit, you could stand up a GitHub replacement for an individual project in 5 minutes using nothing more than a 2-line CGI script. Git fan-boys could continue to use their preferred interface, while others who prefer a more rational and user-friendly design could use the Fossil-like "fit" command. Everybody could share code, and everybody would have a nice web-based interface with which to collaborate with tickets and wiki and all the other cool (and to my mind essential) stuff that Fossil provides. And nobody who already knows git would be forced to learn a new command-line interface. I'd be all over writing the code for "Fit", except that I'm already over-extended. Anybody who thinks this is a good idea and would like to pitch in and collaborate, please contact me privately. Thanks.

winter_blue 9y ago
That sounds like a great idea. By leveraging Fossil's existing UI and getting it to work with Git, it might really gain a lot of traction, and become a viable alternative to roll-your-own-github services like GitLab Community Edition.
EdiX 9y ago
To be attractive to github users it would have to have a better issue tracker and a better patch review system. Given that sqlite uses a mailing list for both I'm guessing it doesn't have that.
voltagex_ 9y ago
This'd be a great idea, but I don't have the skillset.
hinkley 9y ago
The pushback will come in two forms. First, a backend that works exactly like git is very different from one that works almost like git. You'll be blamed for other people's problems. Second, you'll have to have a way to deal with commit history the way git does (arbitrarily, and able to be rewritten at any time) Otherwise the first push -f or rebase breaks the whole thing. Reading from and writing to a git backend (that is, making fit a client too) might be the safer option. Sort of like git-p4 in reverse.

by SQLite 9y ago

winter_blue 9y ago

That sounds like a great idea. By leveraging Fossil's existing UI and getting it to work with Git, it might really gain a lot of traction, and become a viable alternative to roll-your-own-github services like GitLab Community Edition.

EdiX 9y ago

To be attractive to github users it would have to have a better issue tracker and a better patch review system. Given that sqlite uses a mailing list for both I'm guessing it doesn't have that.

voltagex_ 9y ago

This'd be a great idea, but I don't have the skillset.

hinkley 9y ago

The pushback will come in two forms. First, a backend that works exactly like git is very different from one that works almost like git. You'll be blamed for other people's problems. Second, you'll have to have a way to deal with commit history the way git does (arbitrarily, and able to be rewritten at any time) Otherwise the first push -f or rebase breaks the whole thing. Reading from and writing to a git backend (that is, making fit a client too) might be the safer option. Sort of like git-p4 in reverse.