

Gitless – An experimental version control system built on top of Git - mseri
http://gitless.com/

======
chousuke
This seems blog fails to convey the why of gitless. It looks like a very thin
veneer that'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.

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.

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.

~~~
adekok
The index seems to be a git-only feature. It's one of those concepts that's so
simple, it makes you go "Why the hell didn't I think of that?"

The index allows you to have _partially_ staged commits. This is most
important during merges. The merged changes are staged. The unmerged ones are
left in the file system. So the diffs are small.

Every other VCS I've used doesn't handle that case. Merge conflict? Here's a
2000 line diff, of which only 2-3 lines are in conflict. Where are they? Have
fun finding them!

Arg.

Hiding the index makes git easier for newcomers. It also hides a _new_
workflow, unique to git. That workflow is better and more efficient than the
ones for other VCS.

~~~
rbehrends
> Every other VCS I've used doesn't handle that case. Merge conflict? Here's a
> 2000 line diff, of which only 2-3 lines are in conflict. Where are they?
> Have fun finding them!

I am not sure what you're talking about. Every semi-popular VCS I know of
allows you to differentiate between files with and without (or with resolved)
merge conflicts.

Examples (in alphabetical order, because people can get religious here, and I
don't want to appear to favor one over the other):

Bazaar: Integrated in _bzr status_ and also available as a separate _bzr
conflicts_ command.

Fossil: Part of _fossil status_ and _fossil changes_ ; will display files with
conflicts with a CONFLICT rather than EDITED marker.

Mercurial: Here, _hg resolve --list_ or _hg resolve -l_ will list merged
files, both resolved snd unresolved (marked with R and U, respectively).

Monotone: Monotone has _mtn show_conflicts_ and _mtn conflicts show_remaining_
and in general a fairly sophisticated (or complicated, depending on who you
ask) set of commands for analyzing and resolving merge conflicts [1].

Subversion: Conflicts are marked with "C" in _svn status_.

(I've excluded Darcs, which has a model that's quite different from the
traditional merge command, but for the same reason has fairly extensive
machinery for dealing with conflicts, for better or worse.)

[1]
[http://www.monotone.ca/docs/Conflicts.html](http://www.monotone.ca/docs/Conflicts.html)

~~~
david-given
Is the git index just a changelist? (Genuine question --- I've never been able
to get my head around what it's for.) Most VCSes support these, even
Subversion.

~~~
rbehrends
Not quite. The git index (also called staging area) is basically the schedule
of changes that are to make up the next changeset once you hit "git commit".

This is actually why I consider the index an anti-feature. It not only allows
you to do partial commits (practically every VCS does), but encourages it and
there's a good chance that you may do it wrong by accident.

This can result in broken revisions (because you're committing a state that
may have never actually existed on your disk, let alone did compile or passed
tests) and create problems for anything from "git bisect" to nightly builds.

The proper way, as far as I'm concerned, is to do the inverse: use "git stash"
instead to remove all changes that you do not need, then compile and test what
is in your working tree and only then commit the tested version. Afterwards,
apply the stashed changes to get the working tree back to its original state.
This way you can minimize the risk of broken commits.

~~~
Shorel
As a developer that's actually something I love git for. In a big company with
several tickets describing errors in the system, I can work on several issues
at the same time. Or explore different ideas and implementations.

Now, the issue with the compile and testing can be real, but I have an easy
workaround.

I have another working copy/checkout of the repository, called
<repository>-ro. I never edit files in the read only copy, unless it's to fix
a merge conflict. All tests and merges are done in this other copy.

Any revision does eventually exists on disk, in this copy.

~~~
rbehrends
You don't need a staging area if you want to just commit selectively. No VCS
that I know of will stop you from doing just that if you really want to.

    
    
      bzr/fossil/git/hg/mtn/svn commit path1 ... pathn
    

will selectively commit only the listed files/directories (some of them will
even allow you to commit individual hunks, as in "git add -p", if you like to
live dangerously).

The biggest problem with the staging area is that (1) it can happen
accidentally that you forgot to "git add" a file or (2) it really only gives
you any advantage over selective commits when you stage a non-trivial
selection of files, which is exactly where things have a chance of going
wrong.

~~~
obsurveyor
What am I missing, just --amend the commit with the stuff you forgot?

Also, with 'git add -i' you can stage individual hunks of a change instead of
the whole change. This can be useful when you need to break up changes into
multiple commits. I don't think you can 'git stash' your way out of that
situation.

------
jobvandervoort
I'd love to see something that makes git easier to use.

Gitless does not make it clear to me how to work with it in only a handful of
sentences. By that measure, it doesn't seem easier than git.

You say: " We think the problem lies deeper than the user interface, in the
concepts underlying Git"

But it seems to me that you just rely on the same concepts, but rename them or
do nothing at all with them.

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'd be cool if you made
it easier to navigate or make those unique deltas (commits), rather than put a
thin wrapper around them.

~~~
e12e
> I'd love to see something that makes git easier to use.

I'm not really aware of any problems with mercurial's git-support[1]. It might
not really be "working with git", but does support working with (as in pushing
and pulling) git repos. And while I think there'll never be a consensus on
mercurial versus git -- I find that the interface is much cleaner in
mercurial, than with git.

So if by "easier" you mean "easier command line use", I think mercurial is
worth a look. If not, perhaps look at various guis -- but I've not got any
experience with them.

    
    
        hg help git
        Working with Git Repositories
        """""""""""""""""""""""""""""
    
        Basic Use
        ---------
    
        You can clone a Git repository from Hg by running "hg
        clone <url> [dest]".
        For example, if you were to run:
    
          $ hg clone git://github.com/schacon/hg-git.git
    
        Hg-Git would clone the repository and convert it to an
        Hg repository for you.
    
        (...)
    
        If you are starting from an existing Hg repository,
        you have to set up a Git repository somewhere that
        you have push access to, add a path entry
        for it in your .hg/hgrc file, and then run "hg push 
        [name]" from within your repository. For example:
    
          $ cd hg-git # (an Hg repository)
          $ # edit .hg/hgrc and add the target Git URL in
            # the paths section
          $ hg push
    

[1] [http://hg-git.github.io/](http://hg-git.github.io/)

~~~
david-given
Unfortunately, it's not quite that easy --- to be able to push, you need
git+ssh, and I've never made that work with github (it just hangs saying
something about git-upload-pack), and it doesn't seem to help you with some of
the more horrible git interactions, such as doing a pull from upstream to your
forked github repository.

(And I suspect that if I could do that reliably I would have internalised
enough git to use that natively.)

~~~
e12e
Hm... you're right about needing to use ssh+git -- at least with github[1] (I
don't have anything on github yet, I just host my own mercurial repos across a
couple of machines for whatever I'm working on).

However, after forking a repo on github, everything seems to work fine for me:

    
    
        hg clone git+ssh://git@github.com:e12e/QuickTun.git qt.hg
        cd qt.hg
        echo "Mercurial hg-git test." > test
        hg add test
        hg ci -m "Just a test of hg-git push/pull to github."
        hg push
        # outputs:
        pushing to git+ssh://git@github.com:e12e/QuickTun.git
        Warning: Permanently added the RSA host key for IP
        address '192.30.252.131' to the list of known hosts.
        searching for changes
        adding objects
        added 1 commits with 1 trees and 1 blobs
        updating reference refs/heads/master
    

I can see how the need for using ssh could be a problem on windows, where you
need to (AFAIK) get plink/putty working. A quick search seems to indicate that
there's no support for using paramiko (python native ssh client/server) for
the mercurial client.

> it doesn't seem to help you with some of the more horrible git interactions,
> such as doing a pull from upstream to your forked github repository.

Continuing from above, nothing stops you from:

    
    
        hg pull git+ssh://git@github.com:UCIS/QuickTun.git
    

Although working with multiple remotes in mercurial is generally done by
adding them to .hg/hgrc.

Eg adding:

    
    
        upstream = git+ssh://git@github.com:UCIS/QuickTun.git
    

Allows you to do:

    
    
        hg pull upstream
    

and

    
    
       hg push upstream
    

And you can get a sense of what's going on:

    
    
        hg tags
        tip                               59:b6067e2362b5
        default/master                    59:b6067e2362b5
        upstream/master                   58:e5d10c76fcad
    

Not sure if that helps vis-a-vis using git, but as I said, I find the
mercurial commands more intuitive, consistent and friendly -- to the point
that I find it makes quite a difference for me, personally.

That said, if you want to/have to work with github-based repositories, you
might be better off just sticking with git.

[1] [https://github.com/schacon/hg-
git/issues/152](https://github.com/schacon/hg-git/issues/152)

~~~
david-given
Hmm. I never thought it was so simple. I'll have more of a play and see if I
can make it work. I'd _much_ rather use hg than git. Thanks.

------
jacobsimon
I don't think I'd be able to live without "git add -p"

~~~
tokenrove
Seriously. I can't even contemplate what life would be like without it. (And,
particularly, magit's interface for it in emacs)

------
StavrosK
I don't understand all the criticism here. Personally, I don'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.

I saw it the other day and learned to use it with only a page's worth of
reading. Why are so many people confused?

~~~
scrollaway
> I don't understand all the criticism here.

Okay.

> Personally, I don't like and barely ever use the index

And there's why.

A lot of us actually like and use the index a lot. It's incredibly powerful;
one of git's most powerful features in fact.

~~~
StavrosK
You took one of my points and used it to dismiss my entire post. How does my
not liking the index nullify the fact that git is entirely inconsistent?

~~~
scrollaway
Sorry, I did not mean to dismiss your entire post. Your wording suggests that
you don't understand the criticism and confusion, but 90% of it in here (at
the time of this writing) is due to the index being removed which is just:
"wtf?".

I agree that git is insanely inconsistent. I could talk about this for hours.
I'd love a better porcelain. But gitless is removing some pretty critical
stuff here.

On the positive side, I really like the rest of their UI. I especially like
the usage of "track" and "untrack" as core words.

~~~
StavrosK
Some of the criticism is about the index, but most of the rest seems to be
"why gitless?" and "how do I use it?", which are pretty well covered in the
docs, I think.

I agree with you that the removal of the index was a bit orthogonal to the end
goal of making gitless more consistent. I do agree with their decision
(because I don't find the index that useful), but you're right in that they
dumped the baby out with the bathwater by going with simplicity rather than
just consistency.

~~~
chousuke
I read the page, but it's just a short introduction to some of the commands in
gitless; and they're not at all different from git in concept either, except
for the hiding of the index. It does nothing to answer "why" gitless exists,
and why its creators think it's better than git.

I identified several points where gitless' UI is in fact worse than git and as
such am not likely to switch, but I am still interested in the rationale
behind gitless' UI decisions.

I often see people disparaging git's UI, but honestly, I can't see the problem
anymore. Certainly there are weird bits (eg. git diff --cached) in the UI that
I've learned by heart now, but I've also learned git's internals -- which
doesn't require much investment at all since git is extremely simple -- and in
light of that knowledge, git's _behaviour_ is consistent and easily
predictable.

~~~
StavrosK
> Certainly there are weird bits (eg. git diff --cached) in the UI that I've
> learned by heart now

That's the thing, if you've learnt them, gitless is useless to you. I'm not
interested in learning whether a branch is deleted with -d or -D or git rm
branch or whichever one they used for that specific command, so gitless making
them all consistent is definitely an improvement.

~~~
chousuke
I don't think you're seeing my point.

The documentation doesn't do anything to convince the reader that gitless' UI
is more consistent than git's.

Let's pretend I'm a newbie. All I see in the documentation are a list of
commands that have pretty much 1:1 mappings in git. How is it _better_?

~~~
StavrosK
They aren't, though. Have you seen how removals for anything use the same
option, or there's no push or pull, or remotes are much more sane, or creating
repos is the same regardless of whether you're cloning or initting?

It's much more geared towards actions rather than commands.

~~~
chousuke
That's the thing. I haven't seen anything, because the documentation doesn't
mention it. You might be entirely justified, but I can't tell because neither
you or the documentation elaborate on any of my questions.

gitless remotes look exactly the same as git remotes as far as I can tell. Why
are they saner?

git init vs. git clone is a triviality, though I'll grant you that init works
for both use cases

publish is just a synonym for push, and pull is what gitless seems to call
merge. gitless seems to outright ignore the fetch/merge distinction. How do I
fetch commits from a remote repository without merging them?

Overall the impression I get from that single web page of documentation is
that gitless is a porcelain that misses the point on many things. I realize I
might be completely wrong, but gitless' documentation neither answers my
questions nor encourages me to try it out.

You're seeing negative comments wondering about gitless' purpose because the
introduction fails to offer any motivation.

------
zatkin
I don't understand the difference between this and "alias gl=git" in a bash
config.

~~~
Guvante
Implicit index and renaming several things to try and be more consistent.

------
err4nt
I think the problem with a lot of User-Interfaces for Git (whether GUI or TUI)
is that they rename or 'hide' 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's terminology.

Here are the commands I use with Git, they're not that different:

\- git co branchNameHere

\- pull

\- git st

\- git add -all

\- git commit -m "Message here"

\- git push

I am not sure where Gitless would save me time based on what I'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've made (git diff).

Here is my all-time favorite Git command, and I've created an alias called
'showtree' for it, but it helps me to understand where different branches are:

    
    
        git log --all --graph --decorate --oneline --simplify-by-decoration

~~~
lsjroberts
I think you might like tig -
[https://github.com/jonas/tig](https://github.com/jonas/tig) \- it provides a
more interactive version of your showtree command

------
ajanuary
> gl branch name switches to branch name and it creates that branch if it
> doesn't exist

This seems like it would be annoying when you misspell a branch name. Maybe
something like "gl branch -c/\--create"?

~~~
enricosada
like "git checkout -b"

------
hasenj
> We think the problem lies deeper than the user interface, in the concepts
> underlying Git

Like what? And how can you solve "fundamental" conceptual issues by creating a
thin layer on top of git?

------
vasco
Git is so powerful and complex. I do agree that the user interface is poor and
most of the arguments I've heard in favor just sound like the person already
invested a great deal of time learning, and so won'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't wait to see what they mean to do with
merge/rebase in gitless 1.0.

------
shreve
Why can't we all just admit that git is terrible software and move on?

~~~
balabaster
Git isn't really terrible software. Git is really powerful and quite brilliant
in many cases. However, the user experience sucks. Sourcetree went a fair way
to take the pain out of it and have largely done a reasonably good job. Again,
it has its shortcomings, lord knows we could do with a nice easy wrapper that
takes the sting out of nagivating Git and walking us through the work flow
better than the current system.

If you wanna drive stick, you've gotta learn how to use a clutch and
gearshift. You can't expect all of the power without being willing to put in
some sweat equity to learning it.

~~~
shreve
TL;DR: Git really _is_ terrible software.

You're defending VCS in general. Git is a single VCS implementation, and a
shitty one at that.

Git is hacked together from C, Shell, Tcl (which tbh, I've never even heard
of), Python, and C++. Mercurial, by comparison, is Python and C.

Git has an awful UI out of the box. Why? There's no reason other than fuck
you. Mercurial's UI out of the box is similar to every project that has tried
to make Git easier to use. It's for _people_ to use, not Linux kernel
developers. [Humor on this topic:
[http://homes.cs.washington.edu/~asampson/blog/git.html](http://homes.cs.washington.edu/~asampson/blog/git.html)]

Git's documentation also sucks. Suppose you don't understand rebasing. Try
running `git help rebase` and you'll get this back: "git-rebase - Forward-port
local commits to the updated upstream head". WHAT THE FUCK DOES THAT MEAN?

Another example: `git help push` returns "git-push - Update remote refs along
with associated objects". Why is this so goddamn complicated? It's almost like
it was written by developers that have no idea what it's like to not
understand how git works. Oh wait.

Mercurial on the other hand, has simple explanations at first, with more in-
depth explanations if you look further. `hg help push` returns "push changes
to the specified destination". Which is how someone would explain VCS pushing
to another human being.

Linus Torvalds isn't running `git help`, people that don't understand git are.
Documentation should be written for them.

~~~
alsdifu3
All this comment says is that you don't understand git and seem unwilling to
try. Millions of devs use it everyday and seem to like it.

~~~
balabaster
I think "like" might be a strong word :P No compelling alternative is probably
closer to the truth :D

------
awkward
I read, and was perplexed by, this description of git as a "DVCS building
tool" the other day:

[http://lucumr.pocoo.org/2015/2/17/ui-and-hidden-
consistency/](http://lucumr.pocoo.org/2015/2/17/ui-and-hidden-consistency/)

Among other things, I hadn'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.

------
mbil
It'd be nice to see, for some of the most common version control tasks:

1\. The common version control task (e.g. make a new branch and switch to it)

2\. How it's accomplished with Git (e.g. git checkout -b my_new_branch)

3\. How it's accomplished (ostensibly more easily) with Gitless (e.g. gl
branch my_new_branch)

