Gitless: A simple version control system built on top of Git

> But git is that machine. Secretly I think this is the true reason for its popularity.

I think it became popular because it was written to solve the needs of the largest collaborative project in the history of mankind (Linux). It was objectively better for that job than any other tool that was available at the time (and thus for many such collaborative projects), and that's where the popularity came from.

Now, does it have warts? Yes. I don't agree that it requires very detailed knowledge to use effectively (if I was able to figure it out as a high-school student, I'm certain that it's not beyond the majority of developers). I think it's just that many developers don't feel the need to learn how to use their tools effectively, and if a tool isn't as-easy-as-possible for simple tasks (which I will admit is the case for Git -- the index concept appears to really throw people off) then it is seen as being "too hard".

In your scenario, using a CNC machine is a key part of their jobs as CNC operators -- so I would expect that learning how to use the CNC machine they use for their job would be an important part of working there. Similarly, developers who use git daily (and is a central part of their work) really should put the time into learning how to use it effectively (it wouldn't take more than a weekend with the right resources). I don't think it's reasonable to say that a developer whose job it is to use git should not have any burden to learn how to use their tools, and that it's the tools fault for being hard to use.

I don't disagree that the on-boarding with git and some of the UX (such as stashing) is quite bad. But it's nowhere near as hard as people make out, and at the end of the day if you want to use something you should learn how to use it -- just because you can get it to somewhat work after 10 minutes of bashing at your keyboard doesn't mean you shouldn't spend the few extra hours to actually understand what you're doing. git is a transferable skill, and the time taken to learn how to use it pays off very quickly.

My biggest problems with Git are that it doesn't handle large binary objects efficiently, and that it's difficult to treat multiple git repos as a single repo (useful for many things, including keeping versions coherent).

>I could never understand the complaint that Git is "hard to use".

It uses horribly unintuitive metaphors and has weird cryptic methods for doing common, simple tasks that practically require the use of google unless you've memorized the UI.

There's a reason that there is a plethora of wrappers around the system (most of them not very good, unfortunately :().

>In any case, we are supposed to be professionals. Complaining that Git is hard to use is a bit like a machinist complaining that a CNC machine is hard to use.

Gatekeeping is the real reason why git's shoddy UI is tolerated (possibly even celebrated). Knowing and memorizing its quirks is seen as the mark of a "true" professional software developer.

>If you want to accomplish non-trivial things in any field, you have to be prepared to deal with some level of complexity. /rant

I don't agree. 99% of git usage on a project involves a series of repetitive commands following one of about Such a tool would also open up git to non-programmers, allowing easier collaboration. I'd love to see managers tweak configuration properties via git, designers push assets, copywriters push copy and translators push content. I wouldn't have to be the go-between on all of this stuff.

I have a different workflow in TortoiseHg than ufo. In your terminology, I only consider revisions that have been pushed as being baked, while unpushed revisions are the clay. We already have tools to manipulate revisions, while the index, stash/shelve and patches are all just reimplementations of revisions with less convenient UIs. I just go ahead and commit whenever I like (without having to stage!), and sort it out afterwards with a combination of update (like git checkout), revert on specific files (like git reset --soft), and rebase (like git rebase!).

You might say this is trading one complexity (staging area) for another. But you need to be familiar with these commands anyway, so you might as well use the same things for other tasks. Plus, they're visualised on the same revision graph as everything else (e.g. "oh look, one month ago I saved that private commit").

Mercurial has a few properties that make this easier than in git. For example, there is no concept of detached head / garbage collection; when you save a commit, it is simply saved forever unless you choose to forcably remove it. (I have never found myself wishing for Git's refs and heads; they are just straight up unnecessary.) But I could imagine a git wrapper that had these properties too (e.g. when I checkout an old revision, it automatically creates a new branch with a special name that refs the commit I'm leaving behind).

(PS: Having said all of this, 90% of the time I just go ahead and commit and push everything, and 90% of rest of the time it suffices to just untick the checkboxes next to files that I don't want to commit before clicking the commit button in TortoiseHg. This is massively easier than any of these strategies, and it's opt-in. I'm sure there is a command line way to do this but I find a GUI is great for this task because it's quite visual.)

What is tortoisehg doing when you check/uncheck files for commit? I think you can even check/uncheck individual hunks in the diff interface next to the changed-files list. I don't think it's shelving unmarked changes, the changes are still there on disk.

It looks like mercurial has a staging area, just that the default it to stage everything unless the user says so, rather than the other way as in git.

Funny that people are mostly unaware of mercurial supporting this - I would argue not using it by default it pretty user friendly, so long as you know it's there when you need it. I use it pretty often, but it's nice not having the boxes unchecked by default. I usually do want to commit everything.

Relatedly, totoisehg is the reason I don't use git for my personal projects. No git gui that works on Linux comes close.