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.
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.
> 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.)
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.
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.
So much of this comes down to how a particular team uses git and the handling and organization of commits. The only thing you can really "do wrong" with git is push prematurely. Before that, you always have a chance to fix things or tidy things up.
git allows you to package commits up with the interactive rebase before you push them upward to the source. What you commit now isn't necessarily what gets pushed upward. It doesn't matter if you broke the compile with the commit, you still have a chance to fix it before a push. If it hasn't been pushed, no one will necessarily ever know or see it.
The whole point of git is that you can break the crap out of your local repo/branch and still have a chance to fix it before the changes ripple outward and become permanent. It also sounds like you're describing a workflow that entails working off master instead of using feature branches, which is going to create a lot more pain than there needs to be.
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.
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.
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.
I agree! My success rate at trying to split changes into two compilable commits is probably like 50%.
Unfortunately, I don't think stashing helps much either. It's still too cumbersome to stash only some changes. If you're successful on the first shot, awesome. But much like the partial commit case, if the changes you left unstashed don't actually compile or pass tests, adjusting the partition between the changes to commit and not to commit is still a huge pain.
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:
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.
> 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
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.)
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.
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.
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.
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]
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.
One of the reasons that there's not a "nice easy wrapper" that you refer to is that the workflow of using git is very, very different depending on what your role in a project is.
When most people talk about the git workflow, they are thinking of the workflow of a feature developer - which is one of the simpler use cases. Let's think about git, however, as a tool for automating existing workflows, though:
Person #1 is a developer. His workflow looks something like "git fetch public; git checkout -b new-branch public/master; $EDITOR; git commit; git push incoming new-branch". His 'incoming' remote goes to a repository of everyone's unreviewed feature branches, and each feature is parented from the last commit that was in the public repository.
Person #2 is a reviewer. He has two remotes, "incoming" and "reviewed". His workflow is "git fetch incoming; git checkout incoming/branch-to-review; git log --stat; $VIEWER; git push reviewed branch-to-review"
Person #3 is an integrator who's responsible for the state of the 'master' branch on the 'public' repository which is visible to everyone. He only wants to merge reviewed branches. His workflow is "git fetch reviewed; git checkout master; git merge reviewed/branch1 reviewed/branch2 reviewed/branch3; $BUILD_AND_TEST; git push public master".
This is the sort of real-world use of Git that goes on in large organizations. It's actually harder to think about using Git in a single-developer project, because one person is playing the role of developer/reviewer/integrator, and typically doesn't think consciously about what role he's in at any one point in time: so his workflow is sort of a mix of all of the above, which ends up being overly complex.
Tools like SourceTree really don't help the situation either, because they try to give you a graphical interface to git commands in general (since they don't have any insight into the development process for a particular project).
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?
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.
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.
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.
> 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.
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.
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.
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.
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.
47 comments
[ 3.8 ms ] story [ 99.9 ms ] threadThe 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.
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.
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
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.
git allows you to package commits up with the interactive rebase before you push them upward to the source. What you commit now isn't necessarily what gets pushed upward. It doesn't matter if you broke the compile with the commit, you still have a chance to fix it before a push. If it hasn't been pushed, no one will necessarily ever know or see it.
The whole point of git is that you can break the crap out of your local repo/branch and still have a chance to fix it before the changes ripple outward and become permanent. It also sounds like you're describing a workflow that entails working off master instead of using feature branches, which is going to create a lot more pain than there needs to be.
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.
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.
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.
That seems... very wrong?
Unfortunately, I don't think stashing helps much either. It's still too cumbersome to stash only some changes. If you're successful on the first shot, awesome. But much like the partial commit case, if the changes you left unstashed don't actually compile or pass tests, adjusting the partition between the changes to commit and not to commit is still a huge pain.
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:
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)
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.
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.
[1] http://hg-git.github.io/(And I suspect that if I could do that reliably I would have internalised enough git to use that natively.)
However, after forking a repo on github, everything seems to work fine for me:
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:
Although working with multiple remotes in mercurial is generally done by adding them to .hg/hgrc.Eg adding:
Allows you to do: and And you can get a sense of what's going on: 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
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.
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]
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.
> Git has an awful UI out of the box. Why? There's no reason other than fuck you.
Lovely.
When most people talk about the git workflow, they are thinking of the workflow of a feature developer - which is one of the simpler use cases. Let's think about git, however, as a tool for automating existing workflows, though:
Person #1 is a developer. His workflow looks something like "git fetch public; git checkout -b new-branch public/master; $EDITOR; git commit; git push incoming new-branch". His 'incoming' remote goes to a repository of everyone's unreviewed feature branches, and each feature is parented from the last commit that was in the public repository.
Person #2 is a reviewer. He has two remotes, "incoming" and "reviewed". His workflow is "git fetch incoming; git checkout incoming/branch-to-review; git log --stat; $VIEWER; git push reviewed branch-to-review"
Person #3 is an integrator who's responsible for the state of the 'master' branch on the 'public' repository which is visible to everyone. He only wants to merge reviewed branches. His workflow is "git fetch reviewed; git checkout master; git merge reviewed/branch1 reviewed/branch2 reviewed/branch3; $BUILD_AND_TEST; git push public master".
This is the sort of real-world use of Git that goes on in large organizations. It's actually harder to think about using Git in a single-developer project, because one person is playing the role of developer/reviewer/integrator, and typically doesn't think consciously about what role he's in at any one point in time: so his workflow is sort of a mix of all of the above, which ends up being overly complex.
Tools like SourceTree really don't help the situation either, because they try to give you a graphical interface to git commands in general (since they don't have any insight into the development process for a particular project).
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?
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.
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.
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.
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.
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.
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?
It's much more geared towards actions rather than commands.
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.
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.
This seems like it would be annoying when you misspell a branch name. Maybe something like "gl branch -c/--create"?
Like what? And how can you solve "fundamental" conceptual issues by creating a thin layer on top of git?