5 ms·

As a very satisfied long time Git user who also ends up being its biggest advocate and trainer at any organization I end up at... no, it's not easy. It's easy

As a very satisfied long time Git user who also ends up being its biggest advocate and trainer at any organization I end up at... no, it's not easy. It's easy from the perspective of someone who already understands its conceptual model, which is wonderfully elegant. It's not at all easy for beginners. The happy path is fine for the most part. There are several conceptual hurdles to developing basic competence with add, commit, push, and pull, but usually people are able to push past them and get to the point of using those commands even if their purpose and mechanism of action remain mysterious. But things immediately go to hell if something deviates from the happy path. Have you ever seen a beginner try to wrap their head around a merge conflict? Have you ever seen someone try to puzzle through the man pages and Stackoverflow to figure out how to recover from a situation when they can't push, due to remote changes? It often ends in disaster, as they stumble through increasingly opaque and arcane commands, as they mess up the state of their local repository ever further with every copied and pasted snippet. This is not a case of newbies trying to do advanced things they shouldn't be doing. These are "advanced beginner" tasks that arise naturally at some point in just about any workflow. Of course, a lot of this can be ascribed to general lack of competence in doing computer stuff. But Git seems especially disorienting even to people with high general intelligence and years of experience solving difficult technical problems. There's something about its combination of commands that do not map cleanly to the underlying data model, complicated layers of automatic behavior that are only revealed deep within chatty jargon filled reference manual pages (or can only be found in the source code), broadly inconsistent terminology and UI elements, and CLI that tends to be either too verbose or too quiet by default. It's hard to learn and hard to teach. That, in my opinion, makes it hard to use.

adhesive_wombat 3y ago
In my opinion, the biggest thing git could do to be easier to learn is make the "git lola" alias what happens by default when you write "git log". Once you see the graph change as you move about, it all makes a lot more sense. http://blog.kfish.org/2010/04/git-lola.html?m=1 http://blog.kfish.org/2010/04/git-lola.html?m=1
- nerdponx 3y ago
  Agreed, with the caveat that a tangled commit history can be overwhelming to a beginner. Probably the only time I really want to recommend a Git GUI is for visualizing the commit graph. I think GitUp does a really good job of making it navigable and understandable, but is unfortunately Mac-only: https://gitup.co/ https://gitup.co/ If you're interested, here's my version of this: [alias] ## Pretty log graph log-oneline = log --decorate=short --date='format-local:%a %F %H:%M' --pretty='tformat:%C(auto)%h%C(reset) %C(auto,blue)[%ad]%C(reset)%C(auto)%d%C(reset) %aN: %s' log-graph = log-oneline --topo-order --graph reflog-oneline = log-oneline --walk-reflogs lg = log-graph lgl = log-graph --branches --tags lgr = log-graph --branches --tags --remotes lga = log-graph --all For anyone who doesn't want to dig around in the git-log(1) man page, the relevant format placeholder are: %C(col) Change color to "col" %h Abbreviated commit hash %ad Author date (formatted as per --date) %d Ref name (like with --decorate) %aN Author name %s "Subject" (first line of commit message) The difference with the usual `--decorate --pretty=oneline --abbrev-commit` options is that my version includes the date and author name, which can be really helpful when navigating a long commit history and/or a project with multiple contributors. Without it, I often found myself wondering "who did that, and when did they do it?". The --topo-order option also helps here.
_a_a_a_ 3y ago
Agreed, it's a bugger and it's caused me more learning, effort & timewaste than any other piece of software that basically does so little, comparatively speaking, with anything else I use. And I still don't fucking understand it to the point of feeling safe with it.
cmrdporcupine 3y ago
I think of git more as a toolkit for a building bunch of possible revision control systems, each with different workflows rather than a revision control system itself. There's commonalities between them all, but in fact it seems like most new shops I go to work at have very different ideas about what "git" means and the right way to hold the tool. Add in different code review tools and practices and it gets a bit crazy. Mercurial and Bazaar (and in fact Bitkeeper itself when I looked at it back in the day) tend I think to have far more assumptions baked into the CLI about how you'll use them -- or at least they started that way. I think for most teams this is in fact superior, but that's not how the industry went. Because github caught on in the early days, git itself became synonymous with DVCS and modernized revision control right at the time people were finally figuring out that, yeah, not only does CVS suck but Subversion isn't really an improvement. Back then I remember it being often very hard to convince people to try anything new at all, just even to get off CVS. A lot of suspicion, with SVN accepted as a kind of tolerable compromise because it acted mostly like CVS but better. And then the industry kind of just jumped all at once to git, and that was that.

adhesive_wombat 3y ago

In my opinion, the biggest thing git could do to be easier to learn is make the "git lola" alias what happens by default when you write "git log". Once you see the graph change as you move about, it all makes a lot more sense. http://blog.kfish.org/2010/04/git-lola.html?m=1 http://blog.kfish.org/2010/04/git-lola.html?m=1

nerdponx 3y ago
Agreed, with the caveat that a tangled commit history can be overwhelming to a beginner. Probably the only time I really want to recommend a Git GUI is for visualizing the commit graph. I think GitUp does a really good job of making it navigable and understandable, but is unfortunately Mac-only: https://gitup.co/ https://gitup.co/ If you're interested, here's my version of this: [alias] ## Pretty log graph log-oneline = log --decorate=short --date='format-local:%a %F %H:%M' --pretty='tformat:%C(auto)%h%C(reset) %C(auto,blue)[%ad]%C(reset)%C(auto)%d%C(reset) %aN: %s' log-graph = log-oneline --topo-order --graph reflog-oneline = log-oneline --walk-reflogs lg = log-graph lgl = log-graph --branches --tags lgr = log-graph --branches --tags --remotes lga = log-graph --all For anyone who doesn't want to dig around in the git-log(1) man page, the relevant format placeholder are: %C(col) Change color to "col" %h Abbreviated commit hash %ad Author date (formatted as per --date) %d Ref name (like with --decorate) %aN Author name %s "Subject" (first line of commit message) The difference with the usual `--decorate --pretty=oneline --abbrev-commit` options is that my version includes the date and author name, which can be really helpful when navigating a long commit history and/or a project with multiple contributors. Without it, I often found myself wondering "who did that, and when did they do it?". The --topo-order option also helps here.

_a_a_a_ 3y ago

Agreed, it's a bugger and it's caused me more learning, effort & timewaste than any other piece of software that basically does so little, comparatively speaking, with anything else I use. And I still don't fucking understand it to the point of feeling safe with it.

cmrdporcupine 3y ago

I think of git more as a toolkit for a building bunch of possible revision control systems, each with different workflows rather than a revision control system itself. There's commonalities between them all, but in fact it seems like most new shops I go to work at have very different ideas about what "git" means and the right way to hold the tool. Add in different code review tools and practices and it gets a bit crazy. Mercurial and Bazaar (and in fact Bitkeeper itself when I looked at it back in the day) tend I think to have far more assumptions baked into the CLI about how you'll use them -- or at least they started that way. I think for most teams this is in fact superior, but that's not how the industry went. Because github caught on in the early days, git itself became synonymous with DVCS and modernized revision control right at the time people were finally figuring out that, yeah, not only does CVS suck but Subversion isn't really an improvement. Back then I remember it being often very hard to convince people to try anything new at all, just even to get off CVS. A lot of suspicion, with SVN accepted as a kind of tolerable compromise because it acted mostly like CVS but better. And then the industry kind of just jumped all at once to git, and that was that.