
Git Exercises - Aga
https://gitexercises.fracz.com/
======
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](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](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.

------
yebyen
Site is evidently crumbling under load... getting some 50x responses from the
load balancer. (edit: seems ok now?)

~~~
insomniacity
Now getting TLS error!

------
chrisweekly
+1 for well-written FAQs

