Originally based on this 2013 paper.
The name “Gitless” made me think of an alternative version control system: Git without (almost) all the git commands. It would watch the file-system and auto-commit whenever a file changes, so you don’t have to run git commit.
Auto-commits would put the name of the changed file in the commit title. If you use Undo in your file editor to revert to a previous saved version, the VCS would detect that and not create a duplicate commit. Perhaps it would create branches by basing the current commit off the most-similar previous commit, not always the latest one. The VCS would provide a tool to easily browse through the auto-commits, and group, categorize, and annotate them to make them more readable. The history browser would let include heuristics to guess the most important history points, and show less important points as smaller or completely hidden.
Its main benefit would be being low-friction and easy to get started with. If there is a small project that you’re not sure you will be working on long enough to need version control, then just run the command to start watching, and work without bothering about writing commit messages. It would store all history even if you don’t need it, but space is cheap. If the project gets big later and needs serious version control, go back and annotate just the most important history points using the history tool. It would be okay to not annotate everything, thanks to the history browser’s importance heuristics.
Something like this? https://vimeo.com/97711978
I find GIT commands and its use to be dead on spot easy. If it isn’t easy on cli then the GUIs are really good also. If still have issues I can be the jerk and ask why are you using GIT? is there a use case for someone who doesn’t get GIT and needs a hand holding system like gitless that GUIs don’t already do?
From the paper I found it interesting as an attempt to design a set of VCS concepts, w/ associated nouns/verbs, that are sufficiently powerful but fairly simple and orthogonal. From that perspective the implementation on top of git is more of an interoperability thing, vs. designing your own repo format and trying to get people to use that. The website, though, pushes it more as a git front-end, so it’s a bit ambiguous what angle they’re going for.
I find GIT commands and its use to be dead on spot easy.
There are lots of people who disagree.
As for GUIs, the git GUIs I’ve seen are terrible - they’re either simple, but the abstractions are far too leaky (e.g. Github for X), or they expose every option in a way that’s just as complex as the CLI tools (e.g. gitk, SmartGit).
I use the Mac-only GUI Tower, and I love it. It is in the “expose every option” category of GUIs, but I still find it easier to use than the command-line.
Tower’s file diff viewer lets me stage only part of a changed file more easily than the command-line’s git add -i. While git status shows a staged file moving to a separate list, Tower just checks a checkbox next to the file, which I find easier to interpret. Unlike git status, Tower shows when you are in the middle of resolving a merge conflict, and lays out your options to resolve it or abort. And when you switch branches while you have uncommited changes, Tower offers to auto-stash the changes, instead of stopping with an error and making you do it yourself.
git add -i
Tower also simplifies the command-line interface by letting you choose what to interact with by clicking on it, instead of having to type out its full identifier. I can rename a branch just by choosing Rename from its right-click menu and editing the text field, rather than remembering the name of the branch, typing its old name, and and then typing its new name. Or I can rebase changes from master into a feature branch by opening the Rebase panel and hitting Return to accept master, which is selected by default, rather than typing git rebase master.
git rebase master
With all these conveniences, and the extra guidance of seeing what I am working with, I don’t miss the command-line at all.
i find it a bit odd that they have retained the “checkout” metaphor for reverting to a previous copy of a file. that always struck me as one of the mistakes git made; “checking out” a file from the repository history does not suggest that it will overwrite your working copy; some variant of “revert” or “rollback” would have been far better.
edit: this sounds overly negative; i do like the overall idea of building a new set of concepts for a dvcs. i’m just puzzled that they felt this one was worth keeping from git.