10 ms·

Git Command Explorer

289 points by MakisH 5y ago

zeynepevecen 5y ago
This is great UI and idea! I think you can improve it with a search bar. It would be faster.
mid-kid 5y ago
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.
vfclists 5y ago
Stop!! Stop!! Stop!! Just install Emacs and use Magit. You can still use your favourite editor and switch to Emacs for your commit activities. Whats there to loose.
diogenesjunior 5y ago
Besides the heap of javascript, very cool.
sgallant 5y ago
Well done!
spicybright 5y ago
No bisect? Or `log --graph`? Or `git rev-parse HEAD`? Idk, I use the above quite a bit myself. I wonder if it would be more useful in the reverse, where you click your question of what you want to do, then you get the git command and args.
- avgcorrection 5y ago
  Bisect is under debug → binary search.
  - spicybright 5y ago
    Oh, just noticing there's a mix of git specific commands and actions a user would want to take. Like, I wouldn't know what a cherry-pick means if I didn't use git a lot.
    - sabhiram 5y ago
      this exactly :)
overcast 5y ago
Damn yo, that's quite the domain name you snagged for this project! My only criticism would be the "typing", it feels unnecessary, when you just want to navigate quickly around.
- dtgriscom 5y ago
  I'm on the fence about the "typing". It does come across as gimmicky, but it also is a good way to show exactly when the contents of a sizable text field changes.
- kwertyoowiyop 5y ago
  Agree on the “typing.” We’re not watching RPG characters converse.
- srik 5y ago
  I agree; maybe don't type the "note" at least.
- fragmede 5y ago
  contrary opinion: keep the typing. (i'd default to fast and get rid of the toggle though, but you didn't ask.)
chenster 5y ago
Well done! Also check out Tower Git client. It has very good GUI that requires no terminal command.
laurent123456 5y ago
It's nicely done but unfortunately it would still be faster to type something in a search engine and check the result. I think it could improved by adding a free search text box, and maybe by not having a second dropdown list. Instead of making the user select something (sometimes you might no even be sure what to select), display all the options directly - since it's just one line of text anyway it won't take much space.
Gehinnn 5y ago
Related: Git Line Endings configurator. Uses a github action to brute force all combinations. https://hediet.github.io/git-line-endings/ https://hediet.github.io/git-line-endings/
asimpletune 5y ago
Something like this but for git plumbing would be really. Just some way of connecting low level concepts with discovering their corresponding commands.
markussss 5y ago
The "typing" of the results are horrible. It just adds a few seconds where you just sit and wait for the answer to be finished for no apparent reason. Doesn't help that the default is the slow typing speed. I could never recommend this to a colleague to explain or help with git because of how frustrating I find the "typing".
FrontAid 5y ago
bit (https://github.com/chriswalz/bit https://github.com/chriswalz/bit) is a somewhat similar CLI tool for this. It shows command completion alongside a description. PS: We maintain a list of helpful Git CLI tools on https://github.com/frontaid/git-cli-tools https://github.com/frontaid/git-cli-tools
teawrecks 5y ago
I feel like this requires you to already know what all the terminology means and how it translates into commit node manipulation, in which case you don't need something like this. Ex. "cherry-pick" and "bisect" mean very specific things in git that are not obvious. In my experience I understand trees and nodes and how they relate to commits, and I understand the operation I want to carry out on them in terms of trees, I just don't know what git calls it. So I think it would be more useful if it described common desired operations in git-agnostic terms, and then gave me the git command to do that.
ziml77 5y ago
Are there any good CLI wrappers over Git that make it more accessible and consistent? The only one I know of it Gitless and it looks like development on that has stopped. (Also I don't know if it's actually considered good)
- stevage 5y ago
  There were a few. Legit was another.
- bewuethr 5y ago
  Mentioned in another comment: https://qithub.com/chriswalz/bit https://qithub.com/chriswalz/bit I haven't tried it, but it looks promising.
  - bewuethr 5y ago
    Yikes... https://github.com/chriswalz/bit https://github.com/chriswalz/bit, not qithub!
  - ziml77 5y ago
    Oh that one does look cool. I'll certainly be giving it a try.
- avgcorrection 5y ago
  It seems that git(1) was never supposed to be the be-all-end-all regular interface to Git. Other programs were developed alongside it (probably using git(1) under the hood). But they eventually faded into relative obscurity as git(1) grew larger and larger. It’s a catch-22 with programs like git(1): 1. Make a program that is feature-rich and non-opinionated, so you really need to know what you are doing (since the program won’t help you terribly much -- oh you want a DAG, here’s some operations on DAGs... have fun) 2. Become entrenched 3. Now the average developer has to invest so much time in the UI of (1) (because it’s so feature-rich and non-opinionated) that they don’t want to also learn other frontends to it; it’s too much effort
  - 5y ago
breakfastduck 5y ago
The typing reeks of a front end dev doing something fancy at the cost of UX. Like when people add artificial loading to show their really cool spinner. Infuriating. Have it toggle on/off not fast/slow.
sicromoft 5y ago
It's missing a few commands, like git-jolt-ancestor[1] and git-shout-revision[2]. [1] https://git-man-page-generator.lokaltog.net/#am9sdCQkYW5jZXN0b3I= https://git-man-page-generator.lokaltog.net/#am9sdCQkYW5jZXN... [2] https://git-man-page-generator.lokaltog.net/#c2hvdXQkJHJldmlzaW9u https://git-man-page-generator.lokaltog.net/#c2hvdXQkJHJldml...
- advance512 5y ago
  That took me too long :)
lazyant 5y ago
if this had a tree graph or visual aid for some of the commands that would be great
layer8 5y ago
It would be nice to just have a static page with all the content as sections and subsections.
anotherevan 5y ago
The more I use git, the more I like mercurial.
- foresto 5y ago
  About the same functionality, made at about the same time, with an interface made for humans. It's a pity it had to compete with Linus' brand recognition.
  - Aeolun 5y ago
    I eventually switched from Mercurial to Git. The problem is Mercurial is too similar to SVN. All (almost) of the problems I had with SVN I still had with Mercurial. Git is extremely hard to get into, but once you get it you can do anything you want.
    - quleap 5y ago
      Obviously you know nothing about Mercurial
nyanpasu64 5y ago
I was poking through the UI, but the description of "show hashes removed branch or other git objects" is ungrammatical and basically incomprehensible. Additionally I think having two columns so I can see all options without having to open a drop-down menu (which closes and hides the list on click) would allow exploring the choices faster.
octorian 5y ago
Did I miss something, or did they forget to cover "push", "pull", and "branch"? (and possibly a few other very common things)
FailMore 5y ago
Remember
niros_valtos 5y ago
I really don't get the need for it. Open the terminal. Type "man git" and you're done!

289 points by MakisH 5y ago

This is great UI and idea! I think you can improve it with a search bar. It would be faster.

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.

vfclists 5y ago

Stop!! Stop!! Stop!! Just install Emacs and use Magit. You can still use your favourite editor and switch to Emacs for your commit activities. Whats there to loose.

diogenesjunior 5y ago

Besides the heap of javascript, very cool.

sgallant 5y ago

Well done!

spicybright 5y ago

No bisect? Or `log --graph`? Or `git rev-parse HEAD`? Idk, I use the above quite a bit myself. I wonder if it would be more useful in the reverse, where you click your question of what you want to do, then you get the git command and args.

avgcorrection 5y ago
Bisect is under debug → binary search.
- spicybright 5y ago
  Oh, just noticing there's a mix of git specific commands and actions a user would want to take. Like, I wouldn't know what a cherry-pick means if I didn't use git a lot.
  - sabhiram 5y ago
    this exactly :)

overcast 5y ago

Damn yo, that's quite the domain name you snagged for this project! My only criticism would be the "typing", it feels unnecessary, when you just want to navigate quickly around.

dtgriscom 5y ago
I'm on the fence about the "typing". It does come across as gimmicky, but it also is a good way to show exactly when the contents of a sizable text field changes.
kwertyoowiyop 5y ago
Agree on the “typing.” We’re not watching RPG characters converse.
srik 5y ago
I agree; maybe don't type the "note" at least.
fragmede 5y ago
contrary opinion: keep the typing. (i'd default to fast and get rid of the toggle though, but you didn't ask.)

chenster 5y ago

Well done! Also check out Tower Git client. It has very good GUI that requires no terminal command.

laurent123456 5y ago

It's nicely done but unfortunately it would still be faster to type something in a search engine and check the result. I think it could improved by adding a free search text box, and maybe by not having a second dropdown list. Instead of making the user select something (sometimes you might no even be sure what to select), display all the options directly - since it's just one line of text anyway it won't take much space.

Gehinnn 5y ago

Related: Git Line Endings configurator. Uses a github action to brute force all combinations. https://hediet.github.io/git-line-endings/ https://hediet.github.io/git-line-endings/

asimpletune 5y ago

Something like this but for git plumbing would be really. Just some way of connecting low level concepts with discovering their corresponding commands.

markussss 5y ago

The "typing" of the results are horrible. It just adds a few seconds where you just sit and wait for the answer to be finished for no apparent reason. Doesn't help that the default is the slow typing speed. I could never recommend this to a colleague to explain or help with git because of how frustrating I find the "typing".

FrontAid 5y ago

bit (https://github.com/chriswalz/bit https://github.com/chriswalz/bit) is a somewhat similar CLI tool for this. It shows command completion alongside a description. PS: We maintain a list of helpful Git CLI tools on https://github.com/frontaid/git-cli-tools https://github.com/frontaid/git-cli-tools

teawrecks 5y ago

I feel like this requires you to already know what all the terminology means and how it translates into commit node manipulation, in which case you don't need something like this. Ex. "cherry-pick" and "bisect" mean very specific things in git that are not obvious. In my experience I understand trees and nodes and how they relate to commits, and I understand the operation I want to carry out on them in terms of trees, I just don't know what git calls it. So I think it would be more useful if it described common desired operations in git-agnostic terms, and then gave me the git command to do that.

ziml77 5y ago

Are there any good CLI wrappers over Git that make it more accessible and consistent? The only one I know of it Gitless and it looks like development on that has stopped. (Also I don't know if it's actually considered good)

stevage 5y ago
There were a few. Legit was another.
bewuethr 5y ago
Mentioned in another comment: https://qithub.com/chriswalz/bit https://qithub.com/chriswalz/bit I haven't tried it, but it looks promising.
- bewuethr 5y ago
  Yikes... https://github.com/chriswalz/bit https://github.com/chriswalz/bit, not qithub!
- ziml77 5y ago
  Oh that one does look cool. I'll certainly be giving it a try.
avgcorrection 5y ago
It seems that git(1) was never supposed to be the be-all-end-all regular interface to Git. Other programs were developed alongside it (probably using git(1) under the hood). But they eventually faded into relative obscurity as git(1) grew larger and larger. It’s a catch-22 with programs like git(1): 1. Make a program that is feature-rich and non-opinionated, so you really need to know what you are doing (since the program won’t help you terribly much -- oh you want a DAG, here’s some operations on DAGs... have fun) 2. Become entrenched 3. Now the average developer has to invest so much time in the UI of (1) (because it’s so feature-rich and non-opinionated) that they don’t want to also learn other frontends to it; it’s too much effort
- 5y ago

breakfastduck 5y ago

The typing reeks of a front end dev doing something fancy at the cost of UX. Like when people add artificial loading to show their really cool spinner. Infuriating. Have it toggle on/off not fast/slow.

sicromoft 5y ago

It's missing a few commands, like git-jolt-ancestor[1] and git-shout-revision[2]. [1] https://git-man-page-generator.lokaltog.net/#am9sdCQkYW5jZXN0b3I= https://git-man-page-generator.lokaltog.net/#am9sdCQkYW5jZXN... [2] https://git-man-page-generator.lokaltog.net/#c2hvdXQkJHJldmlzaW9u https://git-man-page-generator.lokaltog.net/#c2hvdXQkJHJldml...

advance512 5y ago
That took me too long :)

lazyant 5y ago

if this had a tree graph or visual aid for some of the commands that would be great

layer8 5y ago

It would be nice to just have a static page with all the content as sections and subsections.

anotherevan 5y ago

The more I use git, the more I like mercurial.

foresto 5y ago
About the same functionality, made at about the same time, with an interface made for humans. It's a pity it had to compete with Linus' brand recognition.
- Aeolun 5y ago
  I eventually switched from Mercurial to Git. The problem is Mercurial is too similar to SVN. All (almost) of the problems I had with SVN I still had with Mercurial. Git is extremely hard to get into, but once you get it you can do anything you want.
  - quleap 5y ago
    Obviously you know nothing about Mercurial

nyanpasu64 5y ago

I was poking through the UI, but the description of "show hashes removed branch or other git objects" is ungrammatical and basically incomprehensible. Additionally I think having two columns so I can see all options without having to open a drop-down menu (which closes and hides the list on click) would allow exploring the choices faster.

octorian 5y ago

Did I miss something, or did they forget to cover "push", "pull", and "branch"? (and possibly a few other very common things)

FailMore 5y ago

Remember

niros_valtos 5y ago

I really don't get the need for it. Open the terminal. Type "man git" and you're done!