[HN Gopher] Git Command Explorer
___________________________________________________________________
Git Command Explorer
Author : MakisH
Score : 143 points
Date : 2021-10-16 15:59 UTC (7 hours ago)
(HTM) web link (gitexplorer.com)
(TXT) w3m dump (gitexplorer.com)
| breakfastduck wrote:
| 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.
| asimpletune wrote:
| Something like this but for git plumbing would be really. Just
| some way of connecting low level concepts with discovering their
| corresponding commands.
| markussss wrote:
| 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 wrote:
| 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
| diogenesjunior wrote:
| Besides the heap of javascript, very cool.
| chenster wrote:
| Well done! Also check out Tower Git client. It has very good GUI
| that requires no terminal command.
| sgallant wrote:
| Well done!
| laurent123456 wrote:
| 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.
| mid-kid wrote:
| 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.
| jcranmer wrote:
| 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.
| stevage wrote:
| 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.
| TehCorwiz wrote:
| 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 wrote:
| 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
| AnIdiotOnTheNet wrote:
| And how does one discover that those exist?
| mid-kid wrote:
| "man git", second paragraph.
| sharken wrote:
| 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-...
| _jal wrote:
| try "man git" in your favorite search engine.
| sebazzz wrote:
| Even as a Linux user I prefer online man pages for easier
| navigation.
| wongarsu wrote:
| 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.
| spicybright wrote:
| 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 wrote:
| Bisect is under debug - binary search.
| spicybright wrote:
| 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 wrote:
| this exactly :)
| teawrecks wrote:
| 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.
| overcast wrote:
| 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.
| srik wrote:
| I agree; maybe don't type the "note" at least.
| kwertyoowiyop wrote:
| Agree on the "typing." We're not watching RPG characters
| converse.
| Gehinnn wrote:
| Related: Git Line Endings configurator. Uses a github action to
| brute force all combinations.
|
| https://hediet.github.io/git-line-endings/
| sicromoft wrote:
| It's missing a few commands, like git-jolt-ancestor[1] and git-
| shout-revision[2].
|
| [1] https://git-man-page-
| generator.lokaltog.net/#am9sdCQkYW5jZXN...
|
| [2] https://git-man-page-
| generator.lokaltog.net/#c2hvdXQkJHJldml...
| ziml77 wrote:
| 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 wrote:
| There were a few. Legit was another.
| bewuethr wrote:
| Mentioned in another comment: https://qithub.com/chriswalz/bit
|
| I haven't tried it, but it looks promising.
| bewuethr wrote:
| Yikes... https://github.com/chriswalz/bit, not qithub!
| ziml77 wrote:
| Oh that one does look cool. I'll certainly be giving it a
| try.
| zeynepevecen wrote:
| This is great UI and idea! I think you can improve it with a
| search bar. It would be faster.
___________________________________________________________________
(page generated 2021-10-16 23:00 UTC)