6 ms·

I'll never get why people complain about git being confusing when "man gittutorial" and "man giteveryday" are top-notch entrypoints into the git documentation.

AnIdiotOnTheNet 5y ago
And how does one discover that those exist?
- mid-kid 5y ago
  "man git", second paragraph.
  - sharken 5y ago
    Having recently switched to Git on Windows, you miss out on these great resources. Thankfully with all the Git information floating around it's easy enough to find answers. One such page is this one containing three good tips https://spin.atomicobject.com/2020/05/05/git-configurations-default/ https://spin.atomicobject.com/2020/05/05/git-configurations-...
    - _jal 5y ago
      try "man git" in your favorite search engine.
      - sebazzz 5y ago
        Even as a Linux user I prefer online man pages for easier navigation.
        uuddlrlr 5y ago
        Terminals generally have decent mouse support don't they? Maybe we ought to trick out a man reader.
      - zorr 5y ago
        And if your favorite search engine is DuckDuckGo you can search "!man git"
  - wongarsu 5y ago
    I never bothered typing 'man git' because git offers the 'git help' workflow quite prominently with with quite satisfying results. 'git help everyday' even works, it just doesn't seem to be called out anywhere.
  - SCLeo 5y ago
    > 'man' is not recognized as an internal or external command, operable program or batch file. ...which doesn't exist on Windows. So, are Windows git users are all doomed? Or should all Windows users download WSL in order to access this sacred tutorial?
    - cloakedcode 5y ago
      That’s fair. What environment do you have that installed git at the command line? I’m assuming ‘git’ is a recognized command.
      - recursive 5y ago
        This is the normal state of affairs after running the git installer from git-scm.com
      - drdeca 5y ago
        I’ve attempted to find a way to install man in git bash, but haven’t found a simple way to do so
    - Aeolun 5y ago
      > Or should all Windows users download WSL In general, yes. That would make all our lives a lot easier. Not just in relation to git, but because everyone works off the same base then.
stevage 5y ago
Because the CLI is actually terrible, to the point that academic papers have been written about its terribleness. An intro guide doesn't come close to fixing any of that.
- WalterGR 5y ago
  Git is the only context I’ve heard the term “porcelain” used in. A lovely bit of jargon that as far as I can tell is a more humane interface over a non-humane one. It’s not clear to me which came first: people trying to improve the Git experience by creating porcelain, or the Git project itself distinguishing “porcelain” commands from “plumbing” commands.
jcranmer 5y ago
There are 4 factors. The first one, as other people have already brought up, is that looking through man pages is not the natural entry point for most users. The second factor is that having some good help doesn't excuse the poor quality of most of the rest of the help. It's notable that you don't refer to the "git glossary" as a good entrypoint, especially since (given the next factor I'm about to elaborate), it really ought to be a useful companion. Instead, every time I try to look something up in the git glossary, I somehow end up even more confused than when I started--the help there is literally the opposite of helpful. The third factor is the worst problem with the help: it's absolutely laden with confusing jargon. An example I easily recall is that the "staging area"--the name by which it's pretty universally known to users, in my experience--is almost universally referred to as the "index" in git's documentation, and almost nowhere else is it referred to as that. Index is a particularly bad term in this case because, if I were to list the things in a version control system I might wish to build indexes of, the changes that are being staged for a commit yet to come is not going to rank very high. The final factor is that the poor structure of the git CLI system means that you have to rely on the help. It's notable that the poor CLI of git keeps coming up in discussions about it, far more than any other tool I've ever seen--I can't recall any complaints about any other VCS's CLI, even accounting for their collective (now) lesser popularity. It is pretty clearly objectively bad. A great example that combines many of these points is 'git reset.' Looking at the help documentation, in the opening paragraph: In the first three forms, copy entries from <tree-ish> to the index. In the last form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match. The <tree-ish>/<commit> defaults to HEAD in all forms. It outright starts by admitting that it does different things depending on how its invoked. The help immediately launches into jargon--what is a <tree-ish>? what is the index? If I'm trying to figure out how to do something--say get an older version of a file--this doesn't immediately jump out at me as being what I want...nor does it jump out as not being what I want. I could try laboring through the help here... or I can give up, search the internet for "git get older version of a file" and be reasonably confident that I will get an answer to my question, since somebody has likely asked my question with almost exactly the words I used. And when I choose the latter method, like so many users do, git becomes a list of canned commands that are risky to venture beyond, for if I do, I run the risk of losing data, especially because operations that might repair the repository are not going to be on that list.
kkirsche 5y ago
Git everyday’s web version: https://git-scm.com/docs/giteveryday https://git-scm.com/docs/giteveryday Git tutorial’s web version: https://git-scm.com/docs/gittutorial https://git-scm.com/docs/gittutorial
TehCorwiz 5y ago
I've been using git for years and I've never heard of these. Thanks for shouting them out. This is something I've been thinking about lately. I feel like every tutorial needs a list of documentation right at the top before it gets into whatever specific path through the "forest of knowledge" of the topic at hand.
chefandy 5y ago
Lots of exclusively technical types don't understand why people are confused by heavily documented but awful interfaces. That's why HFE became a field and why UX practices should inform software development from the get-go. Documenting a lousy interface is not a solution— it's a mitigation strategy and usually a lazy one. Most people find git's interface to be confusing, arbitrary, and frequently astonishing in destructive ways. Maybe you're exceptionally gifted in keeping a large bank of seemingly arbitrary commands in your head, or maybe you speak git frequently enough to have native proficiency. Unfortunately, you can't generalize that to all other users, and it doesn't invalidate their difficulty. Since most folks new to git are likely new to CLIs— having a tutorial two levels deep in man pages makes it nearly useless. If you draw two barely touching circles on a page and label one "people confused by git enough to need a tutorial," and the other "people who know what man pages are, how to access and read them, and think to look there for tutorials,"— that's your usability Venn diagram for that documentation. Beyond that, many organizations require non-developers to use git now— copywriters, designers, project managers, etc. We're not talking about sendmail or clang here. That lack of developer empathy for less technical end-users is why software projects, especially FOSS ones, marginalize UX input. Usability is the one thing commercially-sold software consistently does better than FOSS, and one of the reasons commercial offerings so frequently trounce FOSS equivalents in everything but developer and system/network tools used by people with bad UI Stockholm Syndrome. When monetary incentives and non-developer input inform product decisions, "it's in the docs" just doesn't cut it. I've primarily worked in tech for the past 25 years, been a full-time developer for 10 (exclusively writing FOSS,) and have recently moved towards design because I see a lot of unmet needs there. So I understand the frustration in user needs precluding the most elegant/interesting/efficient technical solution to a problem. But, if you aren't actively working to meet end-user needs, frustration about end-user confusion isn't particularly justified. As an aside, I believe Firefox's comparative success among end-user-visible FOSS projects stems from the Mozilla Foundation's commitment to product usability. Check out https://firefoxur.github.io https://firefoxur.github.io
- yarky 5y ago
  > Lots of exclusively technical types don't understand why people are confused... It's not that they don't understand, it's that non-technical people often proactively avoid carefully reading the few lines of relevant documentation. That's something a technical person can tell from the second the non-technical tries to ask a question. > When monetary incentives and non-developer input inform product decisions, "it's in the docs" just doesn't cut it. Obviously, you have the right to ask any question if you're paying for someone's time: you become a "client". Otherwise, yes please read the docs.
recursive 5y ago
For one, git never mentions their existence. For another, now that I've heard of them, I still don't know how to access them.
- db48x 5y ago
  Do you seriously not know how to access man pages?
  - Timwi 5y ago
    The vast majority of people have not heard of man pages, and won't at all be excited or thrilled when you tell them about them. People want to use their computer, not learn how it works. People want to be able to accomplish simple tasks without having to absorb a textbook first.
  - Aeolun 5y ago
    This, exactly, is why using unix is so hard for beginners. I vividly remember being extremely frustrated because every forum post on the topic seemed to assume you understood what they were asking you to do. Man pages can be read by opening a terminal/console window and typing in ‘man [command]’, then pressing enter. Generally you can scroll through them with up/down arrow and pgup/down. Normally the man page name is the same as the command, so I’m not sure how anyone would discover the one for gittutorial.
    - db48x 5y ago
      > Generally you can scroll through them with up/down arrow and pgup/down. Or even your scroll wheel! :D > Normally the man page name is the same as the command, so I’m not sure how anyone would discover the one for gittutorial. At the bottom of every man page there is a SEE ALSO section: SEE ALSO gittutorial(7), gittutorial-2(7), giteveryday(7), gitcvs-migration(7), gitglossary(7), gitcore-tutorial(7), gitcli(7), The Git User’s Manual[1], gitworkflows(7) This is as close to clickable links as man gets; if you want actual links you could run “info git” instead. There is also occasionally a NOTES section: NOTES 1. Git User’s Manual file:///usr/share/doc/git/user-manual.html 2. Trace2 documentation file:///usr/share/doc/git/technical/api-trace2.html 3. Git concepts chapter of the user-manual file:///usr/share/doc/git/user-manual.html#git-concepts 4. howto file:///usr/share/doc/git/howto-index.html 5. Git API documentation file:///usr/share/doc/git/technical/api-index.html It also happens to mention gittutorial(7) and giteveryday(7) in the second sentence of the description, way back at the top of the man page. These are above the fold even in an 80×24 terminal.
deleted 5y ago
[deleted]
laurent92 5y ago
The very simple fact that your GIT help command is unfindable/unguessable/undiscoverable is the essence, the succulent “apéritif” of Git. Fortunately git is majority, so it’s justified to master it. I would not accept that from an OS, for example.

AnIdiotOnTheNet 5y ago

And how does one discover that those exist?

mid-kid 5y ago
"man git", second paragraph.
- sharken 5y ago
  Having recently switched to Git on Windows, you miss out on these great resources. Thankfully with all the Git information floating around it's easy enough to find answers. One such page is this one containing three good tips https://spin.atomicobject.com/2020/05/05/git-configurations-default/ https://spin.atomicobject.com/2020/05/05/git-configurations-...
  - _jal 5y ago
    try "man git" in your favorite search engine.
    - sebazzz 5y ago
      Even as a Linux user I prefer online man pages for easier navigation.
      - uuddlrlr 5y ago
        Terminals generally have decent mouse support don't they? Maybe we ought to trick out a man reader.
    - zorr 5y ago
      And if your favorite search engine is DuckDuckGo you can search "!man git"
- wongarsu 5y ago
  I never bothered typing 'man git' because git offers the 'git help' workflow quite prominently with with quite satisfying results. 'git help everyday' even works, it just doesn't seem to be called out anywhere.
- SCLeo 5y ago
  > 'man' is not recognized as an internal or external command, operable program or batch file. ...which doesn't exist on Windows. So, are Windows git users are all doomed? Or should all Windows users download WSL in order to access this sacred tutorial?
  - cloakedcode 5y ago
    That’s fair. What environment do you have that installed git at the command line? I’m assuming ‘git’ is a recognized command.
    - recursive 5y ago
      This is the normal state of affairs after running the git installer from git-scm.com
    - drdeca 5y ago
      I’ve attempted to find a way to install man in git bash, but haven’t found a simple way to do so
  - Aeolun 5y ago
    > Or should all Windows users download WSL In general, yes. That would make all our lives a lot easier. Not just in relation to git, but because everyone works off the same base then.

stevage 5y ago

Because the CLI is actually terrible, to the point that academic papers have been written about its terribleness. An intro guide doesn't come close to fixing any of that.

WalterGR 5y ago
Git is the only context I’ve heard the term “porcelain” used in. A lovely bit of jargon that as far as I can tell is a more humane interface over a non-humane one. It’s not clear to me which came first: people trying to improve the Git experience by creating porcelain, or the Git project itself distinguishing “porcelain” commands from “plumbing” commands.

jcranmer 5y ago

There are 4 factors. The first one, as other people have already brought up, is that looking through man pages is not the natural entry point for most users. The second factor is that having some good help doesn't excuse the poor quality of most of the rest of the help. It's notable that you don't refer to the "git glossary" as a good entrypoint, especially since (given the next factor I'm about to elaborate), it really ought to be a useful companion. Instead, every time I try to look something up in the git glossary, I somehow end up even more confused than when I started--the help there is literally the opposite of helpful. The third factor is the worst problem with the help: it's absolutely laden with confusing jargon. An example I easily recall is that the "staging area"--the name by which it's pretty universally known to users, in my experience--is almost universally referred to as the "index" in git's documentation, and almost nowhere else is it referred to as that. Index is a particularly bad term in this case because, if I were to list the things in a version control system I might wish to build indexes of, the changes that are being staged for a commit yet to come is not going to rank very high. The final factor is that the poor structure of the git CLI system means that you have to rely on the help. It's notable that the poor CLI of git keeps coming up in discussions about it, far more than any other tool I've ever seen--I can't recall any complaints about any other VCS's CLI, even accounting for their collective (now) lesser popularity. It is pretty clearly objectively bad. A great example that combines many of these points is 'git reset.' Looking at the help documentation, in the opening paragraph: In the first three forms, copy entries from <tree-ish> to the index. In the last form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match. The <tree-ish>/<commit> defaults to HEAD in all forms. It outright starts by admitting that it does different things depending on how its invoked. The help immediately launches into jargon--what is a <tree-ish>? what is the index? If I'm trying to figure out how to do something--say get an older version of a file--this doesn't immediately jump out at me as being what I want...nor does it jump out as not being what I want. I could try laboring through the help here... or I can give up, search the internet for "git get older version of a file" and be reasonably confident that I will get an answer to my question, since somebody has likely asked my question with almost exactly the words I used. And when I choose the latter method, like so many users do, git becomes a list of canned commands that are risky to venture beyond, for if I do, I run the risk of losing data, especially because operations that might repair the repository are not going to be on that list.

kkirsche 5y ago

Git everyday’s web version: https://git-scm.com/docs/giteveryday https://git-scm.com/docs/giteveryday Git tutorial’s web version: https://git-scm.com/docs/gittutorial https://git-scm.com/docs/gittutorial

TehCorwiz 5y ago

I've been using git for years and I've never heard of these. Thanks for shouting them out. This is something I've been thinking about lately. I feel like every tutorial needs a list of documentation right at the top before it gets into whatever specific path through the "forest of knowledge" of the topic at hand.

chefandy 5y ago

Lots of exclusively technical types don't understand why people are confused by heavily documented but awful interfaces. That's why HFE became a field and why UX practices should inform software development from the get-go. Documenting a lousy interface is not a solution— it's a mitigation strategy and usually a lazy one. Most people find git's interface to be confusing, arbitrary, and frequently astonishing in destructive ways. Maybe you're exceptionally gifted in keeping a large bank of seemingly arbitrary commands in your head, or maybe you speak git frequently enough to have native proficiency. Unfortunately, you can't generalize that to all other users, and it doesn't invalidate their difficulty. Since most folks new to git are likely new to CLIs— having a tutorial two levels deep in man pages makes it nearly useless. If you draw two barely touching circles on a page and label one "people confused by git enough to need a tutorial," and the other "people who know what man pages are, how to access and read them, and think to look there for tutorials,"— that's your usability Venn diagram for that documentation. Beyond that, many organizations require non-developers to use git now— copywriters, designers, project managers, etc. We're not talking about sendmail or clang here. That lack of developer empathy for less technical end-users is why software projects, especially FOSS ones, marginalize UX input. Usability is the one thing commercially-sold software consistently does better than FOSS, and one of the reasons commercial offerings so frequently trounce FOSS equivalents in everything but developer and system/network tools used by people with bad UI Stockholm Syndrome. When monetary incentives and non-developer input inform product decisions, "it's in the docs" just doesn't cut it. I've primarily worked in tech for the past 25 years, been a full-time developer for 10 (exclusively writing FOSS,) and have recently moved towards design because I see a lot of unmet needs there. So I understand the frustration in user needs precluding the most elegant/interesting/efficient technical solution to a problem. But, if you aren't actively working to meet end-user needs, frustration about end-user confusion isn't particularly justified. As an aside, I believe Firefox's comparative success among end-user-visible FOSS projects stems from the Mozilla Foundation's commitment to product usability. Check out https://firefoxur.github.io https://firefoxur.github.io

yarky 5y ago
> Lots of exclusively technical types don't understand why people are confused... It's not that they don't understand, it's that non-technical people often proactively avoid carefully reading the few lines of relevant documentation. That's something a technical person can tell from the second the non-technical tries to ask a question. > When monetary incentives and non-developer input inform product decisions, "it's in the docs" just doesn't cut it. Obviously, you have the right to ask any question if you're paying for someone's time: you become a "client". Otherwise, yes please read the docs.

recursive 5y ago

For one, git never mentions their existence. For another, now that I've heard of them, I still don't know how to access them.

db48x 5y ago
Do you seriously not know how to access man pages?
- Timwi 5y ago
  The vast majority of people have not heard of man pages, and won't at all be excited or thrilled when you tell them about them. People want to use their computer, not learn how it works. People want to be able to accomplish simple tasks without having to absorb a textbook first.
- Aeolun 5y ago
  This, exactly, is why using unix is so hard for beginners. I vividly remember being extremely frustrated because every forum post on the topic seemed to assume you understood what they were asking you to do. Man pages can be read by opening a terminal/console window and typing in ‘man [command]’, then pressing enter. Generally you can scroll through them with up/down arrow and pgup/down. Normally the man page name is the same as the command, so I’m not sure how anyone would discover the one for gittutorial.
  - db48x 5y ago
    > Generally you can scroll through them with up/down arrow and pgup/down. Or even your scroll wheel! :D > Normally the man page name is the same as the command, so I’m not sure how anyone would discover the one for gittutorial. At the bottom of every man page there is a SEE ALSO section: SEE ALSO gittutorial(7), gittutorial-2(7), giteveryday(7), gitcvs-migration(7), gitglossary(7), gitcore-tutorial(7), gitcli(7), The Git User’s Manual[1], gitworkflows(7) This is as close to clickable links as man gets; if you want actual links you could run “info git” instead. There is also occasionally a NOTES section: NOTES 1. Git User’s Manual file:///usr/share/doc/git/user-manual.html 2. Trace2 documentation file:///usr/share/doc/git/technical/api-trace2.html 3. Git concepts chapter of the user-manual file:///usr/share/doc/git/user-manual.html#git-concepts 4. howto file:///usr/share/doc/git/howto-index.html 5. Git API documentation file:///usr/share/doc/git/technical/api-index.html It also happens to mention gittutorial(7) and giteveryday(7) in the second sentence of the description, way back at the top of the man page. These are above the fold even in an 80×24 terminal.

deleted 5y ago

[deleted]

laurent92 5y ago

The very simple fact that your GIT help command is unfindable/unguessable/undiscoverable is the essence, the succulent “apéritif” of Git. Fortunately git is majority, so it’s justified to master it. I would not accept that from an OS, for example.