Gitless – An experimental version control system built on top of Git

This seems blog fails to convey the why of gitless. It looks like a very thin veneer that&#x27;s trying to hide the index, which I think is a really bad idea. The index is one of the two main reasons I prefer git over mercurial.<p>The first paragraph says that git has usability issues, but no attempt is made to explain the reasoning and convince the reader that gitless solves these.<p>I also have a UI nitpick: long parameters should have two dashes instead of one so that short parameters can be freely combined; switches like -exc, -inc and -su go needlessly against common convention. You should also not do such arbitrary truncation... --exc and --inc match --exclude and --include unambiguously, so you get shortened forms for free if you simply do a prefix search.

I&#x27;d love to see something that makes git easier to use.<p>Gitless does not make it clear to me how to work with it in only a handful of sentences. By that measure, it doesn&#x27;t seem easier than git.<p>You say: &quot; We think the problem lies deeper than the user interface, in the concepts underlying Git&quot;<p>But it seems to me that you just rely on the same concepts, but rename them or do nothing at all with them.<p>One of the concepts underlying git is a history made of unique deltas that can be referred to at any point in time (+ some change). It&#x27;d be cool if you made it easier to navigate or make those unique deltas (commits), rather than put a thin wrapper around them.

I don&#x27;t think I&#x27;d be able to live without &quot;git add -p&quot;

I don&#x27;t understand all the criticism here. Personally, I don&#x27;t like and barely ever use the index, I think that git is completely inconsistent with itself, and find the design of gitless very consistent and easy to use.<p>I saw it the other day and learned to use it with only a page&#x27;s worth of reading. Why are so many people confused?

I don&#x27;t understand the difference between this and &quot;alias gl=git&quot; in a bash config.

I think the problem with a lot of User-Interfaces for Git (whether GUI or TUI) is that they rename or &#x27;hide&#x27; the Git terminology from users. You still need to know Git to operate the UI, but you often have to learn how Git concepts and terminology map to the UI&#x27;s terminology.<p>Here are the commands I use with Git, they&#x27;re not that different:<p>- git co branchNameHere<p>- pull<p>- git st<p>- git add -all<p>- git commit -m &quot;Message here&quot;<p>- git push<p>I am not sure where Gitless would save me time based on what I&#x27;m seeing, it looks like a simplification of Git. What might save me time would be more features for managing and applying stashes from the command-line, or making it easier to check the changes I&#x27;ve made (git diff).<p>Here is my all-time favorite Git command, and I&#x27;ve created an alias called &#x27;showtree&#x27; for it, but it helps me to understand where different branches are:<p><pre><code> git log --all --graph --decorate --oneline --simplify-by-decoration</code></pre>

&gt; gl branch name switches to branch name and it creates that branch if it doesn&#x27;t exist<p>This seems like it would be annoying when you misspell a branch name. Maybe something like &quot;gl branch -c&#x2F;--create&quot;?

&gt; We think the problem lies deeper than the user interface, in the concepts underlying Git<p>Like what? And how can you solve &quot;fundamental&quot; conceptual issues by creating a thin layer on top of git?

Git is so powerful and complex. I do agree that the user interface is poor and most of the arguments I&#x27;ve heard in favor just sound like the person already invested a great deal of time learning, and so won&#x27;t accept change. A great coat on top of a powerful kernel which eases the 90% use case of git is very welcome in my opinion. I can&#x27;t wait to see what they mean to do with merge&#x2F;rebase in gitless 1.0.

Why can&#x27;t we all just admit that git is terrible software and move on?

I read, and was perplexed by, this description of git as a &quot;DVCS building tool&quot; the other day:<p><a href="http://lucumr.pocoo.org/2015/2/17/ui-and-hidden-consistency/" rel="nofollow">http:&#x2F;&#x2F;lucumr.pocoo.org&#x2F;2015&#x2F;2&#x2F;17&#x2F;ui-and-hidden-consistency&#x2F;</a><p>Among other things, I hadn&#x27;t seen anyone call git consistent before. Still, it made a good case for a project like gitless - because the data structures that back git are very well defined and well specified, the standard command set is more of a suggestion than a necessity.

It&#x27;d be nice to see, for some of the most common version control tasks:<p>1. The common version control task (e.g. make a new branch and switch to it)<p>2. How it&#x27;s accomplished with Git (e.g. git checkout -b my_new_branch)<p>3. How it&#x27;s accomplished (ostensibly more easily) with Gitless (e.g. gl branch my_new_branch)