Guild Alpha Analysis: Discussion

Summary

An analysis of the entire open source “stack” from the perspective of the goals of Guild Alpha. Recommendations will be made alongside each analysis.

Recommendation Targets

  • Lower the barrier to entry for contributing to open-source projects
  • Fast track the learning process of new contributors to equalise the skill set of all open-source contributors
  • Remove barriers for the formation of ad hoc teams
  • Minimise effort required to sustain development

Other Considerations

  • Avoid subscription to a specific ethos (i.e. “cloud-native”) or set of tools
  • Many contributors are not coders
  • Recommendations should be as close to their context as possible

This thread is for discussion and recommendations.

Links:
Research Wiki.

I found this Perforce marketing post on Git LFS.

Perforce is advertising their product, Helix Core, as an alternative to Git LFS. To do that they list all the reasons you may not want to use Git LFS and what Helix Core does better. We can use this to build up a list of possible improvements for Git LFS.

Key Takeaways:

  • For every repo, you have to install Git LFS, tell LFS to track a file type, then add the tracking information to the repo so that when you commit a file of that type, it will be placed in an LFS repository
  • Every user must have Git LFS installed on their server and workstation
  • It does not integrate with popular art and design programs.
  • Non-coders must still pay the performance penalty of large binaries if they have to pull their assets from it.
  • It is a command line-driven tool, so users must learn some commands to get or commit assets. Many artists struggle with this or will not do it. There are some graphical tools for Git LFS, but game engines and design tools do not have good integration with Git, if they have it at all.
  • Being a command line-driven tool also makes it tricky to find the right version of a file, which makes it difficult for artists to iterate on specific assets.
  • GIt LFS’ file locking isn’t user friendly as it doesn’t provide feedback on why a push is denied.

jj-init Article | Author’s Fedi Announcement
Hacker News |

The author, Chris Krycho, talks about a new decentralised version control system called Jujutsu. They detail, in-depth and with a positive skew, their experience with the tool, how it compares to git as well as the possibility of it replacing git in the future.

There’s a mixture of my own words and copy-paste of the article where relevant.

Opening Text Key Takeaways:

  • Jujutsu (jj) is a new version control system from a software engineer at Google, where it is on track to replace Google’s existing version control systems
  • Still in development and doesn’t have it’s own backend yet
  • Built using Rust
  • Problems with Git:
    • Only used because it’s the standard
    • Terrible user experience due to terrible CLI
    • Developers only learn what they need to get by and little more
    • Often suggested dev learn the internals of git but this doesn’t actually help
    • Internals of git have confusing semantics which extends to the interface
  • Has a Git backend so it can be used with existing git repos
    • This also allows devs to use Jujutsu alongside devs who use Git
    • The same dev and use Jujutsu and Git/Git-aware tools interchangeably
  • Changes are distinct from revisions: an idea borrowed from Mercurial, but quite different from Git’s model.
  • Conflicts are first-class items: an idea borrowed from Pijul and Darcs.
  • Supposedly has a “really good” user interface
  • Currently not in a state to be used without git

The above takeaways are from the opening text before the article enters the more technical and more subjective details under the “Using Jujutsu” heading.

Other Key Takeaways:

  • Fairly painless to set up. A single command and editing a .gitignore file for jj specific directories
  • revisions and sets of revisions (revsets) are the the fundamental elements of Jujutsu.
  • Jujutsu has its own functional language. revsets are defined using this language
  • Better log output due to operators acting as functions and a templating system (based on the functional language)
  • Documentation is currently written for those with good knowledge of VCSs and lacks introductory material
  • A change is the equivalent of a commit but due to the nature of Jujutsu works very differently
  • You can modify Change messages and files. You don’t need to do an interactive rebase. You can disable this per branch by making the branch immutable.
  • You can describe (like a commit message) the change you are working on and then keep working on it because the act of describing the change is distinct from the act of “committing”.
  • You can easily commit a change to multiple branches at the same time.
  • Changes can be made at any point in the project history. Jujutsu inserts the change into the history and handles rebasing every child for you without the need for branching.
  • Easily allows you to view how a change has evolved over time with with obslog command
  • It’s hard to select specific file changes to be committed and break them off into their own commit/change.
  • In case of a conflict, Jujutsu can incorporate both the merge and its resolution (whether manual or automatic) directly into commit history.
  • Because Jujutsu understands the conflict markers it can actually just handle them for you often times.
  • Conflicts don’t block you from committing changes
  • Simplified Squash
  • Branches form naturally as you make commits, you can give branches names at any point
  • More coherent CLI terminology and structure
  • Git integration uses libgit2
  • As yet no GUIs or IDE integrations

It seems to me that a lot of these points are about manipulating repo commit histories in a simplified manner.
Another thing to notice is that jj is capable of doing things locally that you normally would do via a forge, this does increase friction though with existing git forges.


I read some of the discussion surrounding the article. This news post was mentioned as well which mentions:

  • Jujutsu also requires a [[Contributor License Agreement]] for contributions.

Sparked an Idea:
So this might be a dumb question but how feasible would it be to create a kind of interoperable protocol for version control or at least distributed version control? From what I know it doesn’t really seem possible per se but who knows worth asking.

Thinking from the perspective that the next gen of version control will need to be compatible with git. I know there’s libgit2.

circlebuilder isn’t sure if it’s feasible either.

I couldn’t find anything regarding it. Maybe a recommendation for simplifying git compatibility for new version control tools.


1 Like