6 ms·

This is interesting. I wonder if he’s actually working on it: Q: If you magically had enough extra time to do one additional thing at work that you’re not doin

This is interesting. I wonder if he’s actually working on it: Q: If you magically had enough extra time to do one additional thing at work that you’re not doing now, what would it be? A: Oh, I’ve got a long list. But my #1 thing right now I think would be a new version control system which the working name is Fit, it’s a combination of Fossil with Git. Uses the Fossil user interface but it uses the low-level file format of Git. So that then you can work with Fossil’s interface but push and pull to legacy Git users. And I think that would be huge.

vouaobrasil 4y ago
That would be really nice. I think there is definitely room for version control for people who are less in the programming realm or who work on personal projects that have a more creative art flavour (writers, desingers, etc). The user interface of Git is too frustrating for these types. Even as a mathematician and somewhat-programmer I dislike Git a lot. Rebase, blame, stash...ugghhh. Although Git is nice I liked Subversion better.
- tokamak-teapot 4y ago
  Have you used Mercurial? I found it a lot more user friendly, especially with TortoiseHg for Windows. Not sure if that’s still around as I don’t use Windows any more but even though there are many similarities, git always feels like it’s designed to solve problems I don’t want to use source control to solve.
  - muxator 4y ago
    TortoiseHg is still maintained and works both on windows (no direct experience) and linux. The development happens on its mailing list, but there is also an Heptapod (a gitlab fork modified to also support mercurial) instance here: https://foss.heptapod.net/mercurial/tortoisehg https://foss.heptapod.net/mercurial/tortoisehg Interesting enough, almost all my work nowadays consists of interacion with git remotes. But my local clone has always been mercurial via hg-git.
  - vouaobrasil 4y ago
    I'll give it a try, thanks!
- eternityforest 4y ago
  Non-programmers aren't going to want any CLI version control, and git-cola plus meld is perfectly fine for simple use cases as long as nobody force pushes or uses a submodule or something like that. Although usually what seems to happen is people only use one linear history and never branch anything. I'm not sure if that's because Git is hard, or just because nobody wants to learn about branches and stuff in any system if they don't have to. In any case it works perfectly fine and is an amazing step up compared to no VCS.
- stavros 4y ago
  The user interface to git is too frustrating for everyone. Most of us just have Stockholm syndrome by now.
_a_a_a_ 4y ago
That would seem to be just a new porcelain for git.
- eesmith 4y ago
  Fossil also supports bug tracking, wiki, forum, email alerts, chat, and technotes. I don't think it's right to call that "just a new porcelain". I have no clue how Hipp thinks to implement it, much less in a way that allows push and pull to legacy Git users.
  - ilyt 4y ago
    I'd imagine legacy users would just see a unconnected branch with a bunch of textfiles. fit-tickets for tickets, fit-wiki for wiki, fit-docs for docs etc.
- marmetio 4y ago
  Isn't that the point of both projects? Git is primarily a file format. There's also a canonical set of low-level command-line utilities. But you can create whatever interface you want. Most programmers and GUIs happen to use the canonical command-line tools, but that's hardly necessary. Fit would keep the necessary part of Git (the file format), and provide a different human interface.
mdaniel 4y ago
> Uses the Fossil user interface but it uses the low-level file format of Git. So that then you can work with Fossil’s interface but push and pull to legacy Git users. I'm surprised that's the #1 magic-wand project for anyone. I'm not trying to yuck his yum, but am just surprised. But the larger elephant in the room for any such effort is that Fossil's mental model is, by choice, way different from git. If they just want a new ui that isn't as "git sux," surely a new cli to kid-gloves git would be less work than trying to reinvent a whole new version control system, and that goes 1000x for trying to maintain wire compat with every git server in the world
- ilyt 4y ago
  I don't think Git wire format changes all that often and old clients work with new servers just fine so I don't think that would be a problem. > But the larger elephant in the room for any such effort is that Fossil's mental model is, by choice, way different from git. How? I've been glancing at docs but I don't see much difference, still a DAG of commits that are named after its hash like almost every other DVCS From onlooker perspective the killer feature seems to be integration with project management tools vs "just" being a VCS
- dahart 4y ago
  > I’m surprised that’s the #1 magic-wand project for anyone. It seems like Dr. Hipp is frustrated that Fossil hasn’t had mainstream adoption, and that git has, he’s talked about it quite a bit in Fossil docs and here on HN. Given that SQLite is very stable and adoption is an absolutely runaway success, I’m not too surprised his wish list now turns to Fossil. > Fossil’s mental model is, by choice, way different from git. Is that accurate? It does come with a ton of extra features, but seems like the core version control model is quite similar conceptually, and differs more on implementation (SQLite backing instead of file system) and workflow dogma (Fossil’s moralizing of rebase and commit graph edits). The Fossil docs even start with “The feature sets of Fossil and Git overlap in many ways.” Fossil was released after but within a year of git being released, the timeline and docs and comments from the authors generally suggest it’s a reaction to git, taking the good parts and trying to, in the authors’ eyes, improve and fix their perceived problems with git.
Cyberdog 4y ago
Git’s UI is difficult, yes, but I’m sure far more people are familiar with it at this point than Fossil. It would be far more inefficient for me to learn Fossil’s commands for what I need Git to do than just continuing to use Git, at least in the short term (and with no guarantees it’ll improve in the long term). If anything, a tool which goes the other way around - allows me to interact with Fossil using familiar Git commands - seems more useful to me.
- eptcyka 4y ago
  This is the case for a lot of tools. There was a time that for a majority of people on the planet, handwriting a letter would be faster than typing it up too.
tiffanyh 4y ago
Super interesting given the purposeful differences between Fossil & Git. https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...
- fbdab103 4y ago
  I think it is just being practical. Much to my chagrin, git has consumed the world. The Fossil tooling offers a reasonably slick (well, not the CSS) out of the box experience which would be nice to have elsewhere.
leeoniya 4y ago
the main reason i'm not all-in on Fossil is because you cannot squash commits; my WIP branch history is very messy, e.g. "looks to be working", "refactor", "typo", "optimize", "undo checkpoint". i don't need any of that junk on the `main` branch once the feature branch is merged. it's really too bad, everything else in Fossil looks very compelling.
- zie 4y ago
  You can hide those commits, you just can't delete/squash them. It's really not as big of a deal as everyone claims.
  - mdaniel 4y ago
    It sounds like you have experience with Fossil; is it that "YOU can hide those commits" meaning you can omit them if you don't get value from them, or is it that "you can HIDE those commits" meaning "UPDATE commit SET hidden = true" so everyone in this "git push --mirror" world also benefits from you declaring the commits to be "of little value"?
    - zie 4y ago
      First, it's discouraged in Fossil, because the right way to do it is to just hide stuff in your "select" view(generally the dashboard in the web UI), so it only shows the stuff you want anyway, i.e. everything is visible, but you select your view to only show the stuff you care about at the time. I.e. don't change the back-end data, change the query you use to view it. If you are bound and determined to hide it by default, then, it's just a flag attached to a commit or a branch(by default in the CLI, it can only apply to branches): fossil amend --hide <branchname> If you want to hide individual commits, you have to work a touch harder: fossil tag add --raw hidden <COMMIT_ID> This thread in the Fossil forums might prove interesting: https://fossil-scm.org/forum/forumpost/333117081652bf3db6dc6f92ccf6682fd1fcd21f205672c2aad253a5fea6e30a https://fossil-scm.org/forum/forumpost/333117081652bf3db6dc6...
      - 4y ago
cryptonector 4y ago
Isn't there something like this already?
nigamanth 4y ago
It's been so long since Git has received a user interface update, that's why GitHub, GitLab and BitBucket had good ideas and made it big. Now I wonder if programmers will ditch Git and go to Fit.
- adql 4y ago
  It's getting small usability updates from time to time. Also GH/GL is popular because of everything else they do (issues, page rendering, now CI/CD) not because git CLI is too hard. Improvements are welcome of course but the moment newbie hits merge conflict no amount of CLI niceness can get around them not knowing what to do with it and that's true regardless of DVCS. For "non-programmers" no CLI is good enough anyway.

vouaobrasil 4y ago

That would be really nice. I think there is definitely room for version control for people who are less in the programming realm or who work on personal projects that have a more creative art flavour (writers, desingers, etc). The user interface of Git is too frustrating for these types. Even as a mathematician and somewhat-programmer I dislike Git a lot. Rebase, blame, stash...ugghhh. Although Git is nice I liked Subversion better.

tokamak-teapot 4y ago
Have you used Mercurial? I found it a lot more user friendly, especially with TortoiseHg for Windows. Not sure if that’s still around as I don’t use Windows any more but even though there are many similarities, git always feels like it’s designed to solve problems I don’t want to use source control to solve.
- muxator 4y ago
  TortoiseHg is still maintained and works both on windows (no direct experience) and linux. The development happens on its mailing list, but there is also an Heptapod (a gitlab fork modified to also support mercurial) instance here: https://foss.heptapod.net/mercurial/tortoisehg https://foss.heptapod.net/mercurial/tortoisehg Interesting enough, almost all my work nowadays consists of interacion with git remotes. But my local clone has always been mercurial via hg-git.
- vouaobrasil 4y ago
  I'll give it a try, thanks!
eternityforest 4y ago
Non-programmers aren't going to want any CLI version control, and git-cola plus meld is perfectly fine for simple use cases as long as nobody force pushes or uses a submodule or something like that. Although usually what seems to happen is people only use one linear history and never branch anything. I'm not sure if that's because Git is hard, or just because nobody wants to learn about branches and stuff in any system if they don't have to. In any case it works perfectly fine and is an amazing step up compared to no VCS.
stavros 4y ago
The user interface to git is too frustrating for everyone. Most of us just have Stockholm syndrome by now.

_a_a_a_ 4y ago

That would seem to be just a new porcelain for git.

eesmith 4y ago
Fossil also supports bug tracking, wiki, forum, email alerts, chat, and technotes. I don't think it's right to call that "just a new porcelain". I have no clue how Hipp thinks to implement it, much less in a way that allows push and pull to legacy Git users.
- ilyt 4y ago
  I'd imagine legacy users would just see a unconnected branch with a bunch of textfiles. fit-tickets for tickets, fit-wiki for wiki, fit-docs for docs etc.
marmetio 4y ago
Isn't that the point of both projects? Git is primarily a file format. There's also a canonical set of low-level command-line utilities. But you can create whatever interface you want. Most programmers and GUIs happen to use the canonical command-line tools, but that's hardly necessary. Fit would keep the necessary part of Git (the file format), and provide a different human interface.

mdaniel 4y ago

> Uses the Fossil user interface but it uses the low-level file format of Git. So that then you can work with Fossil’s interface but push and pull to legacy Git users. I'm surprised that's the #1 magic-wand project for anyone. I'm not trying to yuck his yum, but am just surprised. But the larger elephant in the room for any such effort is that Fossil's mental model is, by choice, way different from git. If they just want a new ui that isn't as "git sux," surely a new cli to kid-gloves git would be less work than trying to reinvent a whole new version control system, and that goes 1000x for trying to maintain wire compat with every git server in the world

ilyt 4y ago
I don't think Git wire format changes all that often and old clients work with new servers just fine so I don't think that would be a problem. > But the larger elephant in the room for any such effort is that Fossil's mental model is, by choice, way different from git. How? I've been glancing at docs but I don't see much difference, still a DAG of commits that are named after its hash like almost every other DVCS From onlooker perspective the killer feature seems to be integration with project management tools vs "just" being a VCS
dahart 4y ago
> I’m surprised that’s the #1 magic-wand project for anyone. It seems like Dr. Hipp is frustrated that Fossil hasn’t had mainstream adoption, and that git has, he’s talked about it quite a bit in Fossil docs and here on HN. Given that SQLite is very stable and adoption is an absolutely runaway success, I’m not too surprised his wish list now turns to Fossil. > Fossil’s mental model is, by choice, way different from git. Is that accurate? It does come with a ton of extra features, but seems like the core version control model is quite similar conceptually, and differs more on implementation (SQLite backing instead of file system) and workflow dogma (Fossil’s moralizing of rebase and commit graph edits). The Fossil docs even start with “The feature sets of Fossil and Git overlap in many ways.” Fossil was released after but within a year of git being released, the timeline and docs and comments from the authors generally suggest it’s a reaction to git, taking the good parts and trying to, in the authors’ eyes, improve and fix their perceived problems with git.

Cyberdog 4y ago

Git’s UI is difficult, yes, but I’m sure far more people are familiar with it at this point than Fossil. It would be far more inefficient for me to learn Fossil’s commands for what I need Git to do than just continuing to use Git, at least in the short term (and with no guarantees it’ll improve in the long term). If anything, a tool which goes the other way around - allows me to interact with Fossil using familiar Git commands - seems more useful to me.

eptcyka 4y ago
This is the case for a lot of tools. There was a time that for a majority of people on the planet, handwriting a letter would be faster than typing it up too.

tiffanyh 4y ago

Super interesting given the purposeful differences between Fossil & Git. https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...

fbdab103 4y ago
I think it is just being practical. Much to my chagrin, git has consumed the world. The Fossil tooling offers a reasonably slick (well, not the CSS) out of the box experience which would be nice to have elsewhere.

leeoniya 4y ago

the main reason i'm not all-in on Fossil is because you cannot squash commits; my WIP branch history is very messy, e.g. "looks to be working", "refactor", "typo", "optimize", "undo checkpoint". i don't need any of that junk on the `main` branch once the feature branch is merged. it's really too bad, everything else in Fossil looks very compelling.

zie 4y ago
You can hide those commits, you just can't delete/squash them. It's really not as big of a deal as everyone claims.
- mdaniel 4y ago
  It sounds like you have experience with Fossil; is it that "YOU can hide those commits" meaning you can omit them if you don't get value from them, or is it that "you can HIDE those commits" meaning "UPDATE commit SET hidden = true" so everyone in this "git push --mirror" world also benefits from you declaring the commits to be "of little value"?
  - zie 4y ago
    First, it's discouraged in Fossil, because the right way to do it is to just hide stuff in your "select" view(generally the dashboard in the web UI), so it only shows the stuff you want anyway, i.e. everything is visible, but you select your view to only show the stuff you care about at the time. I.e. don't change the back-end data, change the query you use to view it. If you are bound and determined to hide it by default, then, it's just a flag attached to a commit or a branch(by default in the CLI, it can only apply to branches): fossil amend --hide <branchname> If you want to hide individual commits, you have to work a touch harder: fossil tag add --raw hidden <COMMIT_ID> This thread in the Fossil forums might prove interesting: https://fossil-scm.org/forum/forumpost/333117081652bf3db6dc6f92ccf6682fd1fcd21f205672c2aad253a5fea6e30a https://fossil-scm.org/forum/forumpost/333117081652bf3db6dc6...
    - 4y ago

cryptonector 4y ago

Isn't there something like this already?

nigamanth 4y ago

It's been so long since Git has received a user interface update, that's why GitHub, GitLab and BitBucket had good ideas and made it big. Now I wonder if programmers will ditch Git and go to Fit.

adql 4y ago
It's getting small usability updates from time to time. Also GH/GL is popular because of everything else they do (issues, page rendering, now CI/CD) not because git CLI is too hard. Improvements are welcome of course but the moment newbie hits merge conflict no amount of CLI niceness can get around them not knowing what to do with it and that's true regardless of DVCS. For "non-programmers" no CLI is good enough anyway.