It's lazy to blame git issues on intellectual laziness. Any human designed system can be learned with enough effort but in git there seems to be significant superfluous effort. Effort that probably makes sense for some use-cases that git was developed for, but as it has become ubiquitous and now we all have to live with it, programmers or not.
In my view, git has too much state. The state of my directory, the state of my branch, the staging area, the stash, etc.. these all interact in non-trivial ways when merging/branching. Gitless shows that it can be done with less state.
And the design of the interface _is_ atrocious:
Anyone who has been in the field understands that for all it's tradeoffs git is an incredible breath of fresh air from systems like CVS/SVN.
That's not an argument. Especially vis a vis the detailed reasoning behind gitless. In my view gitless has a superior experience without losing any power.
Also no one is comparing git to CVS/SVN. It can stand miles above these and still have severe usability flaws.
And I don't work with programmers.
Now, if you have some legitimate gripes about git's usability I'd love to respond to them and have a real discussion, but Gitless doesn't make those arguments, it's just a wrapper around git (which could all be done with aliases) that adds an additional layer of abstraction for no benefit (or at least none that they've felt confident mentioning)
It being "just a wrapper around git" is an excellent argument that the user interface and usability are problematic. Nobody is arguing with the mathematical model underlying git. Gitless manages to expose a lot less state by default. That's a usability win. It's still there when you need it. There is no expressiveness lost. I find the examples they give on their website very persuasive:
If you want the detailed analysis of weaknesses of git that led to the design of gitless, it's here:
https://people.csail.mit.edu/sperezde/onward13.pdf
I don't necessarily agree with everything in there but I think it's an excellent analysis overall and worth reading as a case study anyways.
In my workflow I also see no cost, but I am happy to accept that that's because we don't have very sophisticated needs.
This is generally where I point people who have a technical background
It's definitely fashionable these days to hate on complicated tools. I wonder if the same is true in other professions. Simple tools are easy to use, yes. But anyone who as worked on a Bicycle or other equipment that requires specialized tools knows that the having the correct, often more complicated tool beats the hell out of wacking on it with the wrong type of wrench.
Our expectations of how we interact with software have risen over the years, and that's a good thing.
UX/UI in programs is important. I believe that git has one of the worst, most inconsistent UX's of all time. You can see this by the fractured commands.
Quick examples:
'git reset' vs. 'git revert' and sometime 'git checkout'
'git checkout' vs. 'git clone' vs. 'git pull' vs. 'git fetch' vs. 'git cherrypick'
'git rebase' vs. 'git merge' vs. 'git merge --squash'
Each one of these performs actions on a repo giving you immense power and control to do specific actions, but it's horrible UX. It's very easy to end up in a detached HEAD state, or have accidentally rebased a repo so it's out of alignment with a remote, leaving you with the trouble of dealing with that. It's crap experience, and all I want to do is code. What does it say when resolving these problems the easiest thing is to just reclone the remote repo?
I commend this project for trying to apply some sanity to the entire thing.
It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. The real reason people struggle with git, and I've seen this in many other programs/places is that they rely on discoverability and just randomly try commands until they work.
Git's simplicity is it's downfall. You don't see people wrapping Angular2 in other frameworks to deal with the warts.
There's a reason people are told to look at man pages all the time, the command line is not the place to play "discoverability". There's already plenty of suggestions and help features built into the tool.
> It's crap experience, and all I want to do is code.
- every engineer when first experiencing version control
This let's the design off the hook to easily. Yes, on the one hand this is a great feature, but on the other, you are deleting and restarting your workspace. It's not a great UX, it's just a simple workaround for a bad one.
> - every engineer when first experiencing version control
no, wrong. git is unique in the amount of information that you need to know just to get started with it.
Have you ever worked with a different VCS? How is setting up subversion or CVS any more difficult than going
git init
git add .
git commit -m "initial commit"
Yes, truly a monumental barrier to entry to get started.
http://vasc.ri.cmu.edu/old_help/Archiving/Cvs/cvs_tutorial.t...
If you think git is unique in the amount of information it takes to get started... I pray you work on nothing that even broaches complex.
Yes, I've worked with RCS, CVS, SVN, SourceSafe, Perforce and some others, though know them less well.
Git is bar none the best of all (of which I've had experience) the VCS' out there. I would pick it over anything else. The issues I'm pointing out are not because I don't use it, don't understand it, or don't appreciate it. I just believe that it's too complex.
If git was literally just the set of commands you listed, that would be great. As a single user experience it's hardly ever an issue. But that doesn't mean that it can't be better! And that's why I like this gitless project (and some of the other similar ones out there), it's trying to create a decent experience that will scale.
Also, your example is about creating a new git repo, I find this to be much more rare than getting involved in an already built and multi-member team, which may have all sorts of rules about proper merges or rebases, and such.
There is nothing about gitless that provides a decent experience (compared to git) and certainly nothing about gitless that has anything to do with operating at "scale".
The truth is commands like filter-branch, rebase, cherry-pick, etc. which are notoriously difficult to use... you don't even have to use them.
I'm not saying the git experience can't get better, but the way forward is to modify the existing tools and contribute to the project, not make git wrapper number 84 that does nothing special.
That's a rather condescending thing to say and not accurate or supportive of the view of git you seem to hold.
> The truth is commands like filter-branch, rebase, cherry-pick, etc. which are notoriously difficult to use... you don't even have to use them.
Until someone on the team _does_ use them and then things can become messed up in ways it takes a git expert to figure out how to fix. I've used git for several years and had never even come across filter-branch, I'd have to chase down the git docs to see what it even does. I never had to filter anything with CVS, Continuus, Perforce, SourceSafe or Subversion.
Part of the benefit of the tool is that you can blow everything away and restart. It's distributed, which means you CAN fuck up your local copy and there are no consequences. It's been years since I've had a repository be in an "unrecoverable" state and part of that is actually taking the time to understand what I'm doing as opposed to just crossing my fingers and hoping shit works.
The fact that other version control systems don't even have some of the power features git has is a big reason git is so popular.
Again, if you don't understand the more complicated commands, don't use them (although you should- they are incredibly powerful and worth learning about). If your team is forcing some bizarre workflow on newer developers that involves using filter-branch and cherry-pick all over the place without good reason, that's an organizational issue, not one with git.
For example: 'git reset HEAD~1' is something I use often, it is vaguely like 'git revert <last-hash>'. Therefore I see them as providing similar functions semantically, but not literally.
'git fetch' and 'git cherrypick' are again similar in my mind where one is pulling changes from a remote, while the other pulls a set of changes from one branch into another locally. This is not as good an example though, but I do think they have slightly overlapping concepts.
Could just be my biases I guess.
I have tried and used Mercurial, SVN, RCS, CVS, Bitkeeper, TFS, Bazaar, Perforce, Darcs and of course Git. Granted, Git may not be great, but it is still my first choice.
Darcs is distributed with a different (and interesting) model that doesn't have the cli problems get does.
But honestly for lots of teams dvcs is not that big an advantage (how many teams are syncing around github right now) which means something like Accurev might be a better choice. It uses a concept of streams which is pretty interesting and is GUI oriented which some people like.
Darcs is obviously better than git, but very few people know it exists. And none of free web repositories support it.
That said, my main issue is that git is a good set of primitives for file change management. But its main design principles are not about SCM. It sacrifices ease of workflow for source control, in favor of making centralized maintainer worflows simpler. This is a perfectly fine trade off for a system largely optimized for a few linux kernel maintainers, dealing with lots of distributed and unorganized contributors (frequently over email).
Those same workflows are not necessarily the best way to organize a small (tens of developers) team with a linear history product.
Some time try to onboard a new-grad developer to a team like the former. You spend way more time explaining git internals and data structures than you do source control management. This just isn't true if you do the same thing with other source control systems. Its easier to explain TFS, SVN, hg, perforce or accurev (the systems I have actual working experience with) in every instance.
My opinion is, if bitbucket and github had switched business models early on (ie hg repos for free if they were public and git repos free for private repos) hg would have become the defacto standard. Its just much easier to work with for most development workflows.
Darcs main feature is the simplicity of its data model. Just a pile of patches that compose to produce some code. Push and pull them at will. It's very neat.
Darcs used to have the advantage a nice interactive UI, but git pretty much stole it wholesale with all the '-p' options (git add -p, git checkout -p, git reset -p) so it doesn't win there any more.
Darcs also has the massive downside of not being able to hold more than one branch at a time in a directory. Do you want to switch contexts? 'darcs get' to a new directory and start over. On my most active darcs project I have about 50 directories all with random unpushed WIP patches in them. In git that would just be a bunch of stashes, which are much easier to search through.
Nowadays, if I start tweaking a project that is still in Darcs, I'll immediately switch it to git: https://github.com/purcell/darcs-to-git
Obviously, heavy prior experience with Mercurial does color one's views about UX, but the experience with Git that I have had--and that I have seen many others concur with--is that the UX makes it way too easy to get you in states that you don't know what to do. But that's not the biggest flaw with Git. The biggest flaw is the community: when you don't know what to do, and you start trying to find the answer, instead of being told "this is how you fix it," you instead get a lecture on the full internals of Git, and why the crazy incantation should be really obvious to any user. Is it any surprise that one would find it easier to blow away the directory and recreate the five-line build system fix whose merge conflict caused the mess in the first place?
Your comment is a picture-perfect of this community hostility that I see with Git that I don't see with other VCS. There definitely seems to be a sentiment that there is One True Way™ to do things, and if you're not doing it like that, you are wrong. I care to disagree: a VCS is a tool--it should support my workflow, not dictate it. I find that the community around Mercurial is much more in agreement with the philosophy I hold, and unsurprisingly, I've generally found Mercurial to be superior than Git.
Git is powerful. And also seems to have a powerfully elitist community around it, as evidenced from your comment.
* Some commands require remote branch, others require remote/branch. I can never remember which.
* git lets you create branches with names like 'remote/branch', at which point it starts going crazy because when I then write remote/branch, it doesn't know if I mean branch on remote, or the local branch remote/branch.
* When merging / rebasing goes wrong, it can be hard (or impossible) to recover back to the state I started from.
Looking back at my RCS history (RCS->VSS->MKSSI->CVS->SVN->git) I have to say that all of them were either hard to use or plain bad (VSS).
The problem RCSs are trying to solve is hard, that's why the tools are simultaneously indispensible and frustrating.
You know, like happened to me today.