6 ms·

Is there demand for this? Most real complaints about git are around scalability of giant monorepos, and a lot of work has gone into various solutions. The sec

by wocram 6y ago

Is there demand for this? Most real complaints about git are around scalability of giant monorepos, and a lot of work has gone into various solutions. The secondary complaints about usability seem to be papered over by popularity, and of course the relevant xkcd: https://xkcd.com/1597/ https://xkcd.com/1597/

rudedogg 6y ago
Take a look at https://anu.dev/documentation/associativity.html https://anu.dev/documentation/associativity.html The patch model is simpler IMO
- spockz 6y ago
  Wasn’t the patching fixed already with darcs and mercurial?
  - gwenzek 6y ago
    I don't think Mercurial is patch based. Pijul is more similar to Darcs. They claim to have a sounder and faster patch algorithm. And Anu is apparently even sounder and faster? https://pijul.org/manual/why_pijul.html#pijul-for-darcs-users https://pijul.org/manual/why_pijul.html#pijul-for-darcs-user...
    - Aeolun 6y ago
      How can something be sounder. Either it’s sound or it isn’t.
    - pmeunier 6y ago
      Sounder, no. The theoretical complexity of Anu is improved compared to Pijul. The complexity of Pijul is in O(log l) where l is the number of lines written since the beginning of history, whereas Anu is in O(e) where e is the number of edits. Since each edit has at least one line, this is always better, and Anu can in fact handle large repositories (Linux kernel, Nixpkgs), that Pijul couldln't handle.
      - samatman 6y ago
        Did you mean O(log e)?
  - cbzehner 6y ago
    My understanding was that darcs fixed the model but had fundamental performance problems at _some scale_. I think pijul took the same concepts and tried to streamline them. And this rewrite does that...again?
miloignis 6y ago
The site has https://anu.dev/documentation/why.html https://anu.dev/documentation/why.html For me, I'm excited about better, more rigorous merging and being able to cherry-pick & rollback changes without causing conflicts later on. (Cherry-pick in Git makes a new, unrelated commit, so merging with the branch you cherry-picked from can often cause merge conflicts, etc) In general, tracking and working with actual dependence between patches seems to open up more workflows, and less hacky ones.
rakoo 6y ago
My complaints with git are a bit different, having never felt the burden of giant monorepos (but it's definitely related) git was built as a tool for completely distributed source versioning, but most of us are using it in a centralized way. It's nice to be able to work offline, but when we need to synhcronize there's always a huge dance of fetching first, see if it has moved, merge/rebase, etc... git is good at storing what we did, but it doesn't help at all at saving what we are _doing_: all changes to the working directory are ephemeral, like files stored in ramfs. When working on public repositories, you can't push a branch prefixed with your name; you have to fork the whole project _and_ push a branch before you can start interacting. Instead of having one server and a client, you now have 1 central server, 1 other server that only _you_ can access and will in practice contain 1 branch, and will be abandoned as soon as you're tired of it, and a client. Rights can't be managed at the branch level, so I'm just going to copy-paste the whole thing from the beginning of history and give it to you. What I would like to see in a VCS: - There is one central place where people coordinate - There is exactly one commit associated to a branch, and that association is the same on all machines at the same time (I don't want to git fetch) - If you want to do changes to a branch, you do a sub-branch - That sub-branch, along with your local changes in or out of the staging area, is synchronized to the server. If authorized, other clients can have a view of those as well It seems it already exists with fossil (https://fossil-scm.org/home/doc/trunk/www/concepts.wiki#workflow https://fossil-scm.org/home/doc/trunk/www/concepts.wiki#work...) and with older SCMs, although older SCMs are plagued with the locking problem. In a way the work that is done to handle giant monorepos is helping git move in this direction: all branches are automatically synchronized, and the vision with this kind of repo is that it's ok to commit often, even in small batches. But it's not quite there yet. I've read an account of how things are done in Google (https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...) and it's closer to my dream system.
- felipelemos 6y ago
  > When working on public repositories, you can't push a branch prefixed with your name; you have to fork the whole project _and_ push a branch before you can start interacting. I believe this is more of a issue with GitHub then with git itself.
astine 6y ago
People definitely complain about merging difficulties with Git. The idea with Git is that the data model is simple enough that you can basically manually fix issues that come up. That unfortunately means that you have to take the time to understand Git's data model and not just memorize the interface and a lot of people have complained about that over the years. I think the idea with Anu is that issues don't come up in the first place and that it's hopefully more intuitive to use in the long run.
alkonaut 6y ago
I’d take a new git with just the UX fixed. If the underlying implementation of a new VCS is also better, that’s great, but my main problem with git isn’t that it’s not sound but that the UX is a steaming pile of legacy cruft, and it’s really more an API for version control than a polished interactive app for humans.
- ptx 6y ago
  The OpenBSD developers are apparently working on something[1] like this. Another major focus seems to be privilege separation and security. [1] https://gameoftrees.org/ https://gameoftrees.org/
- pmeunier 6y ago
  > the UX is a steaming pile of legacy cruft This is due to the lack of a solid theory to match the intuition. The "git way" of trying to match each use case is to add a new command for each new use case. I don't think you can fix "just the UX" without fixing the underlying algorithms.
  - alkonaut 6y ago
    As an example of the UX issue: just making command line switches consistent (e.g. delete always being the same switch) would be a very easy fix and a UX win, and it's only compatibility holding that back.
  - rkangel 6y ago
    > The "git way" of trying to match each use case is to add a new command for each new use case. To me, git's problem is the exact opposite - the commands are based on how the underlying technology works, not on the use case for the user. The best example is 'reset'. I understand git's internals reasonably well so I know the reason why, but it's not obvious that you need the same command to "un-add" a file, or to wind history back two commits.
- sideeffffect 6y ago
  have a look at https://gitless.com/ https://gitless.com/ A talk introducing the issues with git and how gitless improves upon them https://www.youtube.com/watch?v=31XZYMjg93o https://www.youtube.com/watch?v=31XZYMjg93o
yyyk 6y ago
There's a lot of internet content praising git's 'simple immutable data tree structure' and how simple it is to implement. git's data structure is also the #1 reason behind limitations that many people try to bypass... e.g. giant monorepos weren't a problem even for ancient centralized VCs because these were file based, and if you wanted to work on a part of the tree it didn't matter - just push and pull the part you care about. But git has a data structure that forces everything in a single tree, so you have to use hacks (submodules etc.). Same thing for the much of the UX and the other complaints (changeset/patch model). When you get down to it, the data structure is behind 90% of difficulties with git.

by wocram 6y ago

rudedogg 6y ago

Take a look at https://anu.dev/documentation/associativity.html https://anu.dev/documentation/associativity.html The patch model is simpler IMO

spockz 6y ago
Wasn’t the patching fixed already with darcs and mercurial?
- gwenzek 6y ago
  I don't think Mercurial is patch based. Pijul is more similar to Darcs. They claim to have a sounder and faster patch algorithm. And Anu is apparently even sounder and faster? https://pijul.org/manual/why_pijul.html#pijul-for-darcs-users https://pijul.org/manual/why_pijul.html#pijul-for-darcs-user...
  - Aeolun 6y ago
    How can something be sounder. Either it’s sound or it isn’t.
  - pmeunier 6y ago
    Sounder, no. The theoretical complexity of Anu is improved compared to Pijul. The complexity of Pijul is in O(log l) where l is the number of lines written since the beginning of history, whereas Anu is in O(e) where e is the number of edits. Since each edit has at least one line, this is always better, and Anu can in fact handle large repositories (Linux kernel, Nixpkgs), that Pijul couldln't handle.
    - samatman 6y ago
      Did you mean O(log e)?
- cbzehner 6y ago
  My understanding was that darcs fixed the model but had fundamental performance problems at _some scale_. I think pijul took the same concepts and tried to streamline them. And this rewrite does that...again?

miloignis 6y ago

The site has https://anu.dev/documentation/why.html https://anu.dev/documentation/why.html For me, I'm excited about better, more rigorous merging and being able to cherry-pick & rollback changes without causing conflicts later on. (Cherry-pick in Git makes a new, unrelated commit, so merging with the branch you cherry-picked from can often cause merge conflicts, etc) In general, tracking and working with actual dependence between patches seems to open up more workflows, and less hacky ones.

rakoo 6y ago

My complaints with git are a bit different, having never felt the burden of giant monorepos (but it's definitely related) git was built as a tool for completely distributed source versioning, but most of us are using it in a centralized way. It's nice to be able to work offline, but when we need to synhcronize there's always a huge dance of fetching first, see if it has moved, merge/rebase, etc... git is good at storing what we did, but it doesn't help at all at saving what we are _doing_: all changes to the working directory are ephemeral, like files stored in ramfs. When working on public repositories, you can't push a branch prefixed with your name; you have to fork the whole project _and_ push a branch before you can start interacting. Instead of having one server and a client, you now have 1 central server, 1 other server that only _you_ can access and will in practice contain 1 branch, and will be abandoned as soon as you're tired of it, and a client. Rights can't be managed at the branch level, so I'm just going to copy-paste the whole thing from the beginning of history and give it to you. What I would like to see in a VCS: - There is one central place where people coordinate - There is exactly one commit associated to a branch, and that association is the same on all machines at the same time (I don't want to git fetch) - If you want to do changes to a branch, you do a sub-branch - That sub-branch, along with your local changes in or out of the staging area, is synchronized to the server. If authorized, other clients can have a view of those as well It seems it already exists with fossil (https://fossil-scm.org/home/doc/trunk/www/concepts.wiki#workflow https://fossil-scm.org/home/doc/trunk/www/concepts.wiki#work...) and with older SCMs, although older SCMs are plagued with the locking problem. In a way the work that is done to handle giant monorepos is helping git move in this direction: all branches are automatically synchronized, and the vision with this kind of repo is that it's ok to commit often, even in small batches. But it's not quite there yet. I've read an account of how things are done in Google (https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...) and it's closer to my dream system.

felipelemos 6y ago
> When working on public repositories, you can't push a branch prefixed with your name; you have to fork the whole project _and_ push a branch before you can start interacting. I believe this is more of a issue with GitHub then with git itself.

astine 6y ago

People definitely complain about merging difficulties with Git. The idea with Git is that the data model is simple enough that you can basically manually fix issues that come up. That unfortunately means that you have to take the time to understand Git's data model and not just memorize the interface and a lot of people have complained about that over the years. I think the idea with Anu is that issues don't come up in the first place and that it's hopefully more intuitive to use in the long run.

alkonaut 6y ago

I’d take a new git with just the UX fixed. If the underlying implementation of a new VCS is also better, that’s great, but my main problem with git isn’t that it’s not sound but that the UX is a steaming pile of legacy cruft, and it’s really more an API for version control than a polished interactive app for humans.

ptx 6y ago
The OpenBSD developers are apparently working on something[1] like this. Another major focus seems to be privilege separation and security. [1] https://gameoftrees.org/ https://gameoftrees.org/
pmeunier 6y ago
> the UX is a steaming pile of legacy cruft This is due to the lack of a solid theory to match the intuition. The "git way" of trying to match each use case is to add a new command for each new use case. I don't think you can fix "just the UX" without fixing the underlying algorithms.
- alkonaut 6y ago
  As an example of the UX issue: just making command line switches consistent (e.g. delete always being the same switch) would be a very easy fix and a UX win, and it's only compatibility holding that back.
- rkangel 6y ago
  > The "git way" of trying to match each use case is to add a new command for each new use case. To me, git's problem is the exact opposite - the commands are based on how the underlying technology works, not on the use case for the user. The best example is 'reset'. I understand git's internals reasonably well so I know the reason why, but it's not obvious that you need the same command to "un-add" a file, or to wind history back two commits.
sideeffffect 6y ago
have a look at https://gitless.com/ https://gitless.com/ A talk introducing the issues with git and how gitless improves upon them https://www.youtube.com/watch?v=31XZYMjg93o https://www.youtube.com/watch?v=31XZYMjg93o

yyyk 6y ago

There's a lot of internet content praising git's 'simple immutable data tree structure' and how simple it is to implement. git's data structure is also the #1 reason behind limitations that many people try to bypass... e.g. giant monorepos weren't a problem even for ancient centralized VCs because these were file based, and if you wanted to work on a part of the tree it didn't matter - just push and pull the part you care about. But git has a data structure that forces everything in a single tree, so you have to use hacks (submodules etc.). Same thing for the much of the UX and the other complaints (changeset/patch model). When you get down to it, the data structure is behind 90% of difficulties with git.