[da_chicken]

This is actually pretty well done, but I can't help but feel like the number of articles and documents trying to explain or teach git is a sign that the tool just has usability problems.

Maybe I'm misremembering, but I don't remember people having so much trouble with svn. With rcs and cvs, sure, and it was mainly stuff with breaking locks, moving files, and other BS that were part of the bad design. With svn I remember the problems being: setting up the daemon (https vs svnserve+ssh), fixing a wedged Berkeley DB when that was still a thing, and getting hook scripts working right cross-platform. With git, the common problem seems to be: "what command am I even supposed to use here?" and "I broke it somehow and I don't know how to fix it." If the number of articles about it ever seemed to go down I might say, "Oh, it's just growing pains for new users," but they still seem to be out there constantly. Why is everybody still having trouble learning to use git?

Note to the zealots: This isn't to say git is bad, anymore than vi/vim is bad for having it's own arcane interface that users have complained about and struggled with for decades. Lots of terrific software carries burdens like a terrible interface, or an onerous configuration, or a lack of documentation. That doesn't mean we can't be critical.

[westoncb]

I think this is a commonly recognized issue—for instance, here is some research explicitly addressing the problem: https://spderosso.github.io/onward13.pdf ("What's Wrong with Git? A Conceptual Design Analysis")

What makes the issue most clear to me is just looking at the language used in various git commands, and asking how related it is to the abstract task I'm actually trying to accomplish. More often than not, the choice of words makes sense in connection with the implementation of various git operations, but has no relation to the task you're attempting to accomplish.

I believe that situation is a consequence of the UI being centered around several data structures at the heart of git's operation. So, if you learn, first, that those data structures exist at all, how they're used, and how the various commands relate to them—then you can start becoming proficient at git, and the language used in the commands makes a kind of sense even from a design perspective.

IMO, the main thing missing is a way of seeing git's core data structures updated in real-time as you perform various operations on them. Instead we mostly rely on manually kept mental models of them—and on making backups before trying new things ;) I think this project I'm working on could potentially work really well for giving a real-time visualization of git's data structures: http://symbolflux.com/projects/avd (not that I can imagine any realistic route for incorporating it with the git codebase, though...—but in principle.)

[da_chicken]

That's an interesting paper.

> More often than not, the choice of words makes sense in connection with the implementation of various git operations, but has no relation to the task you're attempting to accomplish.

This seems like an extremely common problem in computing. I support several applications and a lot of the fields and functions in those applications seem to be placed arbitrarily until you know that those fields live in the same table or those functions are a part of the same module or class. Users find the organization very confusing because the model of what they need when doesn't match how it's organized in the system. The user shouldn't need to know about those sorts of implementation details because that knowledge isn't their problem. The program interface should follow a natural workflow, not force the user's workflow to match the implementation.

> IMO, the main thing missing is a way of seeing git's core data structures updated in real-time as you perform various operations on them.

I think that would be a great help for troubleshooting those really obscure or weird situations, but I don't think that's information that your average git user should feel like they need to know to get work done.

[westoncb]

> This seems like an extremely common problem in computing.

I agree—I see it all over the place. It's what you get for a UI by default, if you don't take any extra measures to seek an effective design: you just expose program internals.

I think the situation with git is slightly different from that all too common, naive pattern, though. The best comparison I can make is to graphics APIs like OpenGL (or even better, Vulcan), which are there in large as a means of giving access to graphics hardware, very low-level and a horrible impedance mismatch for actually describing moving images. However, they are necessary because the variety of things people might want to do with a graphics card is so vast, that 'nicer' abstractions will always also be restrictions on capabilities. So, you get OpenGL/Vulcan and rather than using it directly to build applications, it's the basis for building other graphics libraries which actually have good usability. (But also like git, there are many cases where people just need to use the low-level APIs directly, despite poor usability.)

Git seems to be addressing a similar issue in that any abstraction over the internal core data structures ends up limiting the vast spectrum of potential use cases, so it makes the compromise of providing (relatively) un-abstracted access to the program's core data structures, which maximizes use-cases covered, and sacrifices usability. But, the generality it provides leaves open the possibility of building higher-level abstractions on top of it... I know a bunch of these exist in various forms, CLI and GUI, and for me anyway, none that I'm aware of cover everything I need to do with git—but I believe such an application could be built and the community would stabilize on using it for 90% of cases instead.

As far as visualization of its data structures goes, I see it fitting in as training wheels essentially: it would be an effective way of teaching people how the program works by allowing them to see the direct impact of particular git commands on the git data structures. Eventually you stop using it, except for troubleshooting really weird/obscure situations, as you mention. (More generally, I could see open source projects offering a flag so that their core data structures are visualized or not as a means of more effectively/enjoyably teaching new developers how data moves around in the app at a high level.)

[nlawalker]

>> But, the generality it provides leaves open the possibility of building higher-level abstractions on top of it [...] I know a bunch of these exist in various forms, CLI and GUI, and for me anyway, none that I'm aware of cover everything I need to do with git—but I believe such an application could be built and the community would stabilize on using it for 90% of cases instead.

The beauty of being able to use an abstraction on top of git is that it doesn't need to cover everything you do. You can use a GUI or a couple simple aliases or scripts for daily driving and then move to the CLI for surgery; a good GUI will have a CLI pane or a button to open a CLI in the right directory.

Even for simply committing, it's nice to have the GUI visualization as an easy sanity check that you haven't accidentally added tons of files, or as an easy way to browse your changes before committing.

Stabilizing on git itself is good enough, there's no need for everyone to use the same abstraction on top of it. The only reason there's so much focus on the CLI is because it's the default, and because power users keep convincing newbies that you're not cool if you don't use it.

[w0rd-driven]

From SVN I cut my teeth on Hg/Mercurial, which had a much simpler barrier to entry and feels more user friendly. Mercurial and git solve the same basic underlying problem, distributed repositories, but in the "next gen vcs war" (if that was even a thing), git won out by a huge landslide largely due to a little site called Github.

As I've dived into the nitty gritty of both, I find it seems you can get more out of git because it just exposes those internal structures unabashedly. I believe it's those guts that make git as powerful or as hard as it currently is on UX. To use a loose analogy, git feels like man pages: rocket science speak but incredibly dense whereas Mercurial is like a very lightweight howto site. It's easier to transition to Mercurial but once you find you need to dive deep, it's just about as complex as git. Git seems to throw you in the deep end immediately which I do think is more of a blessing than a curse but there are times when it doesn't quite feel that way.

[y4mi]

you clearly never had to support developers that need to work with a basic git-flow and get merge conflicts because they're unable to figure out why they shouldn't do the same change in separate branches. Or, if they do, how to resolve that conflict themselves.

[da_chicken]

To be fair, these are the same developers who moved files and renamed folders in SVN without using "svn mv".

[aklemm]

No other Unix-style tool has reached so far into programmer land. Needing all these great docs and lessons is just what it takes to get this type of tool widespread adoption. Some things are just kinda hard, and managing code is one of them.

[yebyen]

What is a simple (or should I say easy?) workflow that allows three (or three hundred) people to work on the same codebase? I'd challenge that there isn't one, and that sometimes a complex problems has a complex solution.

I think the fact is that many people have worked with git on their own, and then they may think that they know git.

Many of those people then go on to work on a small project with hardly any devs working concurrently on the same code, but just enough to run into problems they didn't have before. This way you get the brightest of those people to start to understand that no, unless you've worked on a Git project with a team and handled the issues that comes along with that experience, you don't actually know Git yet.

Unfortunately with smaller teams, those people often learn Git so well (and, to be fair, "so well" is only marginally better than the person who works on Git by themselves, but getting to know it that well is still a substantial barrier, because git merge conflicts are pain, and pain is naturally avoided, but one can only learn to solve a problem by rote, ... by rote, or by repeating the solution.)

...that the rest of their team often doesn't have to learn the hard parts at all. That person then "handles the git issues." You don't really need to get Mad Git Skillz if you don't have a need to deal with those issues, and if your company's core competency is solving git merge conflicts, then you know you have a problem... anyway...

As team size approaches "the Linux kernel" or similarly byzantine and gargantuan project scope, the frequency of having "those issues" increases and the absolute number of "git people" needed to handle them obviously goes up. Maybe if you're lucky, the proportion of people who know Git well enough to solve the hard problems also goes up, so as a member of the team, your frequency of encountering a Git Person who might impart some Git Wisdom onto you will also go up.

Git isn't only good for teams that need to solve hard problems like OS kernels though. Some teams don't ever need to solve especially hard problems (not to belittle those teams, and notwithstanding that "complex" and "hard" can be separate, and the domain of hard problems is vast and many teams that do solve "hard" problems still don't need to solve hard git problems.)

But they still know they need Git to do their jobs. Those teams may learn enough Git, then dodge the bullet and never "get a Git person" and they are absolutely still really using Git productively.

They're using Git to solve a problem that it solves, they're just not using Git to solve hard problems. They may even get really good at avoiding encountering those hard problems before they ever need to spend the time to learn to solve them, from repeated exposure to let's call them "merge traumas."

And you will get successful teams on both ends of the spectrum.

Not to stray too far from the topic at hand, this site and the exercises look great. I like the mix of easy and hard problems. I like that the word "rebase" is nowhere to be found on the front page, but as a person who knows how to use rebase (and struggles to explain it to my team sometimes) it was very easy to find the exercise that will teach it, and see that it is not an especially difficult example at all.

The fact that Git is successful I think can be attributed strongly to the fact that Git can make solving some very hard problems possible and with great ease, when you have become "a git person."

[orev]

Look at Mercurial for an example of an interface that is much better, and it accomplishes basically the same thing as git.

[yebyen]

I went looking for Mercurial documentation about how to rebase and found this:

> Rewriting of history has ramifications if you’ve previously pushed those commits elsewhere. In Mercurial, you simply cannot push commits that you later intend to rebase, because anyone pulling from the remote will get them. In Git, you may push commits you may want to rebase later (as a backup) but only if it’s to a remote branch that only you use. If anyone else checks out that branch and you later rebase it, it’s going to get very confusing.

Git does not tell me what I cannot do. Can you explain how this documentation is wrong, or how I'm wrong for what I want to do here? I'm talking about "git pull --rebase"

Because in Git, I know that canonical wisdom is you should not rebase a branch once it's published, but Git does not tell me what I cannot do, and it happens all the time ("Committer, master has moved some since your PR was submitted, please pull rebase.") Out of respect for contributors time (and some of whom won't know what to do, and may spend time struggling to figure it out...), I would probably not rewrite a commit that's been published in a master branch, but I will absolutely rewrite commits all the time on branches that are not yet merged.

So, can you explain how this workflow goes in Mercurial? (Or why it's unnecessary?) Because from briefly perusing the first document I could find about my question, it looks like Mercurial cannot be used to solve this problem (the solution of which, I find to be a fundamental and very important part about how Git works.)

[dboreham]

git pull --rebase doesn't rebase a pushed commit. It only rebases commits you have made locally, which therefore have not been seen by others.

[yebyen]

Then committer can either 'git push --force' which apparently is not allowed by mercurial too? Or create a new branch.

I try to clean up working branches when they are not needed anymore. I get the idea that Mercurial users think I shouldn't do that, or that I shouldn't share my working branches.

[BeetleB]

Although I'm not a power user, I believe mercurial can do pretty much most things that git does - including editing history. They just make the easy stuff easy and make the advanced stuff harder - as opposed to git which puts them all on an equal footing.

For history editing, people use the evolve extension in mercurial. It'll likely never become part of the default mercurial because there is a small chance of breaking backward compatibility.

Even before the evolve extension, there were ways to modify mercurial history.

Yes, mercurial docs leave something to be desired. But the actual interface is much cleaner than git's, and is much more newbie friendly, without really losing anything sophisticated.

As another user said in another comment:

>It's easier to transition to Mercurial but once you find you need to dive deep, it's just about as complex as git. Git seems to throw you in the deep end immediately which I do think is more of a blessing than a curse but there are times when it doesn't quite feel that way.