4 ms·

boy, does this guy's ethos for fossil impress me a lot more than the justifications i hear for the insane complexity of git. to me, this kind of result is the

boy, does this guy's ethos for fossil impress me a lot more than the justifications i hear for the insane complexity of git. to me, this kind of result is the most compelling argument that the world of high tech isn't nearly so much a meritocracy as it is made out to be.

masklinn 7y ago
> boy, does this guy's ethos for fossil impress me a lot more than the justifications i hear for the insane complexity of git. git is not complex though. It just has an absolutely godawful "high-level" user interface. Porcelain (high-level commands) are really shortcuts on sets of low-level operations usually performed together, which is why e.g. `checkout` is used simultanously for reverting working copy chances and switching the entire thing to arbitrary commits or branches. That also makes git extremely hard to learn "top down" beyond rote learning of a few commands: from that POV the CLI is completely incoherent so you can't really build an intuition for what command could do what operation. The terrible naming doesn't help either. If you have the time and desire to start from the on-disk storage (ignoring packfiles) you can build your own in a few hours.
- Smaug123 7y ago
  This is slowly improving, at least; `git switch` is now a thing, for example. https://git-scm.com/docs/git-switch/2.23.0 https://git-scm.com/docs/git-switch/2.23.0
  - capableweb 7y ago
    At a glance, it seems to do the same as `git checkout` and `git checkout -b`. Can someone give a TLDR about the difference? Edit: gonna be fun to see how guides like https://www.atlassian.com/git/tutorials/using-branches/git-checkout https://www.atlassian.com/git/tutorials/using-branches/git-c... are becoming outdated in a way where switching/checking out doesn't mean the same thing anymore, but the article uses them interchangeably
    - masklinn 7y ago
      These three invocations are not present in switch: git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>… git checkout [<tree-ish>] [--] <pathspec>… git checkout (-p|--patch) [<tree-ish>] [--] [<paths>… ] That is, aside to / on top of the ability to switch to a specific branch or commit, checkout * is used to revert working tree changes, possibly interactively * is used to set working tree changes to either side of a merge (in case of conflict) * is used to revert specific local paths to a historical version thereof, possibly interactively
- pnako 7y ago
  Regarding the last point: some OpenBSD developers are currently writing their own front end ("got") using the same on-disk structure as git. http://gameoftrees.org/goals.html http://gameoftrees.org/goals.html
  - masklinn 7y ago
    That looks interesting. However there have been lots of "porcelain replacements" efforts in the past, but most of them either were abandoned because by the time they'd built something complete enough the author had had to so deeply understand the underlying model they could use the official fine, or remained niche because they were extremely opinionated (and limited) with respect to the workflows they'd support.
    - lima 7y ago
      The point of that project is to create a BSD-licensed Git clone, not build better porcelain.
      - wolrah 7y ago
        Nah, the point is definitely not to create a Git clone. They're developing their own system designed around a more centralized structure than Git (closer to CVS/SVN), but remaining compatible with Git on disk.
orhmeh09 7y ago
I encourage you to read its source code, a mishmash of several dialects of tcl, html and js and sql inlined in c, etc. I made an effort to use fossil throughout the summer, but lack of tooling + a lot more git experience caused me to abandon it except for some existing repositories. Note, I have tremendous respect for the authors of fossil and I hope for its success in the long term.

masklinn 7y ago

> boy, does this guy's ethos for fossil impress me a lot more than the justifications i hear for the insane complexity of git. git is not complex though. It just has an absolutely godawful "high-level" user interface. Porcelain (high-level commands) are really shortcuts on sets of low-level operations usually performed together, which is why e.g. `checkout` is used simultanously for reverting working copy chances and switching the entire thing to arbitrary commits or branches. That also makes git extremely hard to learn "top down" beyond rote learning of a few commands: from that POV the CLI is completely incoherent so you can't really build an intuition for what command could do what operation. The terrible naming doesn't help either. If you have the time and desire to start from the on-disk storage (ignoring packfiles) you can build your own in a few hours.

Smaug123 7y ago
This is slowly improving, at least; `git switch` is now a thing, for example. https://git-scm.com/docs/git-switch/2.23.0 https://git-scm.com/docs/git-switch/2.23.0
- capableweb 7y ago
  At a glance, it seems to do the same as `git checkout` and `git checkout -b`. Can someone give a TLDR about the difference? Edit: gonna be fun to see how guides like https://www.atlassian.com/git/tutorials/using-branches/git-checkout https://www.atlassian.com/git/tutorials/using-branches/git-c... are becoming outdated in a way where switching/checking out doesn't mean the same thing anymore, but the article uses them interchangeably
  - masklinn 7y ago
    These three invocations are not present in switch: git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>… git checkout [<tree-ish>] [--] <pathspec>… git checkout (-p|--patch) [<tree-ish>] [--] [<paths>… ] That is, aside to / on top of the ability to switch to a specific branch or commit, checkout * is used to revert working tree changes, possibly interactively * is used to set working tree changes to either side of a merge (in case of conflict) * is used to revert specific local paths to a historical version thereof, possibly interactively
pnako 7y ago
Regarding the last point: some OpenBSD developers are currently writing their own front end ("got") using the same on-disk structure as git. http://gameoftrees.org/goals.html http://gameoftrees.org/goals.html
- masklinn 7y ago
  That looks interesting. However there have been lots of "porcelain replacements" efforts in the past, but most of them either were abandoned because by the time they'd built something complete enough the author had had to so deeply understand the underlying model they could use the official fine, or remained niche because they were extremely opinionated (and limited) with respect to the workflows they'd support.
  - lima 7y ago
    The point of that project is to create a BSD-licensed Git clone, not build better porcelain.
    - wolrah 7y ago
      Nah, the point is definitely not to create a Git clone. They're developing their own system designed around a more centralized structure than Git (closer to CVS/SVN), but remaining compatible with Git on disk.

orhmeh09 7y ago

I encourage you to read its source code, a mishmash of several dialects of tcl, html and js and sql inlined in c, etc. I made an effort to use fossil throughout the summer, but lack of tooling + a lot more git experience caused me to abandon it except for some existing repositories. Note, I have tremendous respect for the authors of fossil and I hope for its success in the long term.