6 ms·

I’m excited to see there is still work being done on new VCS. Git will be hard to beat, but it looks like Anu is hitting on some of its weak points.

minerjoe 6y ago
> Git will be hard to beat. With the latest kurfuffle at Github, I've started moving to fossil. Having everything, wiki, pull requests, etc. as part of the repo is looking like a good move. Why let yet another corporation have control over something they should have never been given? https://fossil-scm.org https://fossil-scm.org
- andrewzah 6y ago
  github != git ... I'm not sure why people strongly conflate these two so much. It would be equally as valid to self-host gitea/gogs/sourcehut/gitlab and/or an issue tracker of your choice, which arguably is preferable to adopting a completely different tool over what is a provider issue.
  - reificator 6y ago
    While that's a common conflation I don't think the GP was doing that. While I tend to self-host git, I can see the value they're claiming fossil has. Whether self-hosted git or hosting on Github, your issue trackers and such are typically separate from your main repository. Most platforms offer wikis as a side-by-side repository so that should be easy to move, but the rest is at the whims of the platform. The GP is claiming they moved to fossil because the one repository contains all of this data.
  - wtracy 6y ago
    I think minerjoe is trying to emphasize that fossil has all the features of GitHub included in the VCS itself, eliminating the need for any of the tools you listed above. I haven't followed Fossil, so hearing that it includes things like a wiki is news to me.
  - dan-robertson 6y ago
    I think all git has going for it is its existing inertia and GitHub. I think the foundations were a bigger deal when git was newer. Other DVCSes have decent foundations. Going against git is an atrocious user interface (if it were good then [1] would be neither funny nor sad). Most people just memorise a few commands and if they stop working they transfer their changes elsewhere, delete the repo, and start again. Sometimes a team will have a “git expert” who has merely memorised a few more commands and is better able to get a repo out of a broken state. Git fails badly at an important for a developer tool: largely getting out of the way. [1] https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
    - reificator 6y ago
      You'll never hear me say that git's interface is good, but this seems to be blowing things way out of proportion. I haven't seen someone blow up and recreate a git repo in maybe a decade. I've definitely pulled out the BFG here and there to clean up credentials but that's an issue in any VCS. Maybe I'm biased because I'm "better able to get a repo out of a broken state", but for the record it's definitely not because I've "memorised a few more commands".
    - theon144 6y ago
      Your attitude seems to mirror this xkcd https://xkcd.com/1597/ https://xkcd.com/1597/ and I honestly never understood it. I'm by no means a git expert (I've actually just recently learned about bisect for instance), but I have never in my entire career been in a state where I'd just delete the repo and recreate it from scratch. I've only ever used a handful of commands, the most advanced of which could be probably considered `reflog` when I wanted to revert some changes; or `rebase` (because strictly speaking, it is more complex than merge I guess), but I never ran a command I did not understand or had to memorize. I actually do share the sentiment about the tool getting out of your way, and my knee-jerk reaction to learning about git internals is just repulsion, because you're right! I'm not there to tinker around with version control, I'm there to solve problems. That said, I've never felt like Git got in my way.
      - 6y ago
  - badsectoracula 6y ago
    minerjoe is mentioning Fossil specifically because unlike Git it also provides the features (in a broad sense) that GitHub provides (wiki, bug tracker, discussion forum, news/blog, "released" files and of course version control) while remaining fully distributed - these are stored and versioned as part of the repository itself. As a nice bonus Fossil is a single executable/binary file you can drop anywhere and can act as both the CLI for working with the repository and as the web backend with a bunch of ways to access it including CGI, it's own web server or even as a fake script parser (you can upload the linux binary to any shared host that supports custom script parsers -many do- and use a "script" with a shebang that calls the binary with the path to the repository file, thus allowing you to use Fossil with shared hosting services that do not even know about it).
- deleted 6y ago
  [deleted]
- swiley 6y ago
  >Why let yet another corporation have control over something they should have never been given? I'm pretty sure github doesn't control git.
  - minerjoe 6y ago
    That's not what I was implying. They have control over the pull-requests, the wiki, and all the other meta information.
alquemist 6y ago
What are those weak points and how does Anu fix them? I found a technical example in https://anu.dev/documentation/associativity.html https://anu.dev/documentation/associativity.html, but it was unconvincing. In their example, three way merge should produce a conflict for a human to resolve it. Which is good, we don't want a 'smart' tool to do the wrong thing and silently introduce bugs. If the argument is that pijul/anu reduce the number of conflicts by exploiting history, is there a quantization of this benefit for practical workloads, e.g. popular git repos?
- IshKebab 6y ago
  I agree. Also in their example they lose a nice property of git - invariance to squashing. If Alice squashes her two changes then the final merge behaves differently to if she hadn't. Very confusing! Git definitely could be much smart about merge conflicts, but it's a hard research problem so I'm not surprised it isn't.
- andolanra 6y ago
  That example, while technically correct, is a little bit misleading. From a practical point of view, the thing that Pijul/Anu both do is not "automatically resolve conflicts" but rather "allow repo operations to happen even in the presence of conflicts". In Git, if you've got a conflict, Git will require you to fix it before doing anything else. In Pijul or Anu, you can continue applying changes—possibly creating more conflicts!—in a way that's guaranteed to never throw away changes. At the end of that, a human still needs to resolve those merges manually. But there are scenarios in which this avoids tedious human merges. Consider that I'm applying a series of patches which make changes in a file and later on walk those changes back, and run into a merge conflict there. In Git, I could squash those changes to avoid dealing with the conflict, but then I've lost history. I could apply the changes, skipping the relevant patches, but if those patches still contained useful work elsewhere, then I'd have to go in and resolve those problems manually. In contrast, this same scenario in Pijul and Anu would just trivially work in a way that didn't produce conflicts. I would apply the sequence of patches, and one patch would produce a conflict… but because they can keep doing work in the presence of conflicts, then they could keep applying subsequent patches and apply the patches which walk back the changes, and in that resolve the conflict automatically, but unlike the Git approach where I flattened the changes first, I would still have the full commit history associated with that sequence. Now, that doesn't mean that Pijul or Anu will automatically fix all merges. If you have two separate code edits to reconcile, you might still need a human in the loop to reconcile them. But the fact that they can keep making changes in the presence of conflicts allows them to avoid a certain kind of "busywork" that comes with managing git history.
5d749d7da7d5 6y ago
> Git will be hard to beat If I were the Anu people, I would focus on having a seamless compatibility layer that could manage Git <-> Anu repositories (there are undoubtedly many headaches that would occur synchronizing the two different models). This would allow developers to silently interact with ongoing git repos using the "better" tool. Getting wholesale migration to a new platform seems a significant challenge, but allowing developers to slowly build mind share with an improved workflow would be possible. Disclaimer: I hate git.
- jhvkjhk 6y ago
  Compatible with old projects is the main reason why modern software suck, look at zsh, c++. Some times we need to shift to a brand new paradigm.
  - HelloNurse 6y ago
    Git (and less popular competitors that are close in age and design principles, like Mercurial, Darcs and Fossil) is what everyone is using and therefore what needs compatibility, not an "old project" holding back progress. That role is filled by Subversion, CVS, VSS etc. with their tragic anti-features.
- pmeunier 6y ago
  `cargo install anu --version 1.0.0-alpha --features git` gives you a one-way incremental import, with the command `anu git`.
- gnufx 6y ago
  For what it's worth, darcs can consume and produce git import/export streams. I've synced a darcs repo with git and mercurial mirrors with cron (to avoid slowing down commits by doing it in a hook).

minerjoe 6y ago

> Git will be hard to beat. With the latest kurfuffle at Github, I've started moving to fossil. Having everything, wiki, pull requests, etc. as part of the repo is looking like a good move. Why let yet another corporation have control over something they should have never been given? https://fossil-scm.org https://fossil-scm.org

andrewzah 6y ago
github != git ... I'm not sure why people strongly conflate these two so much. It would be equally as valid to self-host gitea/gogs/sourcehut/gitlab and/or an issue tracker of your choice, which arguably is preferable to adopting a completely different tool over what is a provider issue.
- reificator 6y ago
  While that's a common conflation I don't think the GP was doing that. While I tend to self-host git, I can see the value they're claiming fossil has. Whether self-hosted git or hosting on Github, your issue trackers and such are typically separate from your main repository. Most platforms offer wikis as a side-by-side repository so that should be easy to move, but the rest is at the whims of the platform. The GP is claiming they moved to fossil because the one repository contains all of this data.
- wtracy 6y ago
  I think minerjoe is trying to emphasize that fossil has all the features of GitHub included in the VCS itself, eliminating the need for any of the tools you listed above. I haven't followed Fossil, so hearing that it includes things like a wiki is news to me.
- dan-robertson 6y ago
  I think all git has going for it is its existing inertia and GitHub. I think the foundations were a bigger deal when git was newer. Other DVCSes have decent foundations. Going against git is an atrocious user interface (if it were good then [1] would be neither funny nor sad). Most people just memorise a few commands and if they stop working they transfer their changes elsewhere, delete the repo, and start again. Sometimes a team will have a “git expert” who has merely memorised a few more commands and is better able to get a repo out of a broken state. Git fails badly at an important for a developer tool: largely getting out of the way. [1] https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
  - reificator 6y ago
    You'll never hear me say that git's interface is good, but this seems to be blowing things way out of proportion. I haven't seen someone blow up and recreate a git repo in maybe a decade. I've definitely pulled out the BFG here and there to clean up credentials but that's an issue in any VCS. Maybe I'm biased because I'm "better able to get a repo out of a broken state", but for the record it's definitely not because I've "memorised a few more commands".
  - theon144 6y ago
    Your attitude seems to mirror this xkcd https://xkcd.com/1597/ https://xkcd.com/1597/ and I honestly never understood it. I'm by no means a git expert (I've actually just recently learned about bisect for instance), but I have never in my entire career been in a state where I'd just delete the repo and recreate it from scratch. I've only ever used a handful of commands, the most advanced of which could be probably considered `reflog` when I wanted to revert some changes; or `rebase` (because strictly speaking, it is more complex than merge I guess), but I never ran a command I did not understand or had to memorize. I actually do share the sentiment about the tool getting out of your way, and my knee-jerk reaction to learning about git internals is just repulsion, because you're right! I'm not there to tinker around with version control, I'm there to solve problems. That said, I've never felt like Git got in my way.
    - 6y ago
- badsectoracula 6y ago
  minerjoe is mentioning Fossil specifically because unlike Git it also provides the features (in a broad sense) that GitHub provides (wiki, bug tracker, discussion forum, news/blog, "released" files and of course version control) while remaining fully distributed - these are stored and versioned as part of the repository itself. As a nice bonus Fossil is a single executable/binary file you can drop anywhere and can act as both the CLI for working with the repository and as the web backend with a bunch of ways to access it including CGI, it's own web server or even as a fake script parser (you can upload the linux binary to any shared host that supports custom script parsers -many do- and use a "script" with a shebang that calls the binary with the path to the repository file, thus allowing you to use Fossil with shared hosting services that do not even know about it).
deleted 6y ago
[deleted]
swiley 6y ago
>Why let yet another corporation have control over something they should have never been given? I'm pretty sure github doesn't control git.
- minerjoe 6y ago
  That's not what I was implying. They have control over the pull-requests, the wiki, and all the other meta information.

alquemist 6y ago

What are those weak points and how does Anu fix them? I found a technical example in https://anu.dev/documentation/associativity.html https://anu.dev/documentation/associativity.html, but it was unconvincing. In their example, three way merge should produce a conflict for a human to resolve it. Which is good, we don't want a 'smart' tool to do the wrong thing and silently introduce bugs. If the argument is that pijul/anu reduce the number of conflicts by exploiting history, is there a quantization of this benefit for practical workloads, e.g. popular git repos?

IshKebab 6y ago
I agree. Also in their example they lose a nice property of git - invariance to squashing. If Alice squashes her two changes then the final merge behaves differently to if she hadn't. Very confusing! Git definitely could be much smart about merge conflicts, but it's a hard research problem so I'm not surprised it isn't.
andolanra 6y ago
That example, while technically correct, is a little bit misleading. From a practical point of view, the thing that Pijul/Anu both do is not "automatically resolve conflicts" but rather "allow repo operations to happen even in the presence of conflicts". In Git, if you've got a conflict, Git will require you to fix it before doing anything else. In Pijul or Anu, you can continue applying changes—possibly creating more conflicts!—in a way that's guaranteed to never throw away changes. At the end of that, a human still needs to resolve those merges manually. But there are scenarios in which this avoids tedious human merges. Consider that I'm applying a series of patches which make changes in a file and later on walk those changes back, and run into a merge conflict there. In Git, I could squash those changes to avoid dealing with the conflict, but then I've lost history. I could apply the changes, skipping the relevant patches, but if those patches still contained useful work elsewhere, then I'd have to go in and resolve those problems manually. In contrast, this same scenario in Pijul and Anu would just trivially work in a way that didn't produce conflicts. I would apply the sequence of patches, and one patch would produce a conflict… but because they can keep doing work in the presence of conflicts, then they could keep applying subsequent patches and apply the patches which walk back the changes, and in that resolve the conflict automatically, but unlike the Git approach where I flattened the changes first, I would still have the full commit history associated with that sequence. Now, that doesn't mean that Pijul or Anu will automatically fix all merges. If you have two separate code edits to reconcile, you might still need a human in the loop to reconcile them. But the fact that they can keep making changes in the presence of conflicts allows them to avoid a certain kind of "busywork" that comes with managing git history.

5d749d7da7d5 6y ago

> Git will be hard to beat If I were the Anu people, I would focus on having a seamless compatibility layer that could manage Git <-> Anu repositories (there are undoubtedly many headaches that would occur synchronizing the two different models). This would allow developers to silently interact with ongoing git repos using the "better" tool. Getting wholesale migration to a new platform seems a significant challenge, but allowing developers to slowly build mind share with an improved workflow would be possible. Disclaimer: I hate git.

jhvkjhk 6y ago
Compatible with old projects is the main reason why modern software suck, look at zsh, c++. Some times we need to shift to a brand new paradigm.
- HelloNurse 6y ago
  Git (and less popular competitors that are close in age and design principles, like Mercurial, Darcs and Fossil) is what everyone is using and therefore what needs compatibility, not an "old project" holding back progress. That role is filled by Subversion, CVS, VSS etc. with their tragic anti-features.
pmeunier 6y ago
`cargo install anu --version 1.0.0-alpha --features git` gives you a one-way incremental import, with the command `anu git`.
gnufx 6y ago
For what it's worth, darcs can consume and produce git import/export streams. I've synced a darcs repo with git and mercurial mirrors with cron (to avoid slowing down commits by doing it in a hook).