Git Has A New Wire Protocol Yielding Much Greater Performance

[brrrrttttt]

If you don't require/understand the power why not just use some cookie-cutter GUI like GitKraken? It's actually a pretty good way to learn your way around and you may later find more and more of your git workflow moves to the terminal.

[starshipeleven]

Imagine being an elitist Linux user who thinks shit UX is some sort of trial of worthiness.

If we were talking of shit UI we would talk of PowerShell. Git is fine.

[starshipeleven]

Yes, but it is not intuitive which makes it difficult to use it right of the bat and you have to spend time learning it. Since its incoherent it is unnecessary difficult to learn.
Then when you haven't used it in a while, you forget how to use it since its incoherent and you have to look things up again to figure out how do them.

Maybe it's just me, but I never remember how most shell command really work beyond the basic stuff (grep/awk/package managers), I just google up (or read the man) and if I know I will need to do that again on a regular basis then write down a script that does what I need, and then next time I just call that.

I really don't think commandline tools can be really user-friendly once the tool is doing anything more than basic dumb operation or it is a guided wizard asking the user and giving him a list of options to choose, you will always need to call the help/manual and read before you must do stuff unless you can memorize dozens of nearly nonsensical -a -b -c or --longer-command1 --longer-command2.

I mean, who the fuck remembers tar (or even cp) arguments anyway? They invented GUIs for a reason. On a GUI I see buttons that use icons to try to convey what they stand for, on a commandline tool I have no idea of what I can give it as arguments unless I read up its man (or memorize it).

[Tomin]

Something that I recently found out is that git has aliases. I had already defined some of my own commands with git-command named scripts but now I also use its aliases for simple cases. My favourite is git today alias that shows me commits since yesterday.

Also, I don't find git commands illogical. If there is a space between origin and master then it is a remote and a branch and if there is a slash, so origin/master, then it's a refspec. Branching and rebasing are something I do a lot nowadays and I find it easy enough to do.

Btw, for tar I remember that I need f for archive file, c to create an archive, x to extract and then I usually want also an a with c to use (any, automatically detected) compression. Sometimes I might want to use t to list (test?) files inside the archive I'm working on. If I need something more complex, then I check --help or man page as usual.

[LubosD]

UX? Seriously, who the heck uses a GUI client for git? It's so much powerful from the command line.

[abott]

uid313 I find it very intuitive. I've also spent about 2 hour learning it, but it was worth it and can do basically any common thing without even thinking about it.

[Royi]

I use SmartGit which is great!
This way I only need to understand the concept of GIT but not to know to use its CLI.
SmartGit is also cross platform so it acts the same on Linux, Windows and macOS.

[Citan]

I would like to see some improvements to the Git client.
It is not intuitable to use. It is pretty incoherent and unpredictable.

Very laughable. It's easy to use and very powerful once you take time to learn it. You are not worthy.

Either you're a troll, or you're just so full of yourself you must have trouble finding shoes to your size, poor lad that you are.

Git commandes are *objectively* counter-intuitive. Having the same command bringing a completely different behaviour just depending on the parameter is an insult to the bare principles of user experience (case in point: checkout commit vs checkout file).

The fact that it is actually logical because of how it was conceived is irrelevant: when you have to explore a tool's code to understand how it works, because you need to understand how it works to understand how to use it even for the most basic use-cases, you've failed as far as ease of experience goes.

With that said, I understand why it's like this: it's a tool made, at the origin, by great developers for great developers, aka people...
- Who don't bear using code they don't understand in the first place, so obviously prying into code is not a problem for them (and it's a big relief for end-users of their products too XD).
- Who live by and through command line, so any way to shorten the number and lengths of commands to memorize is a boon for them, and checking help / piping commands is like breathing for them.
- Who have been heavily involved in collaborative process in general (and code versioning system in particular) since years so many things have become second nature to them (collaboration concept, good practices etc) when those things are actually not at all.

Honestly, just one batch of renaming some commands (some bad choices in vocabulary and "implicit meaning") and aliasing subsets/specific cases of others (precisely to characterize the difference in effect), and explaining the reasons why certains choices of "default behaviour" (like merge vs merge --squash), would resolve >80% of the usability/understanding problems for new users.

As it is now, you just can't understand how Git really works without making a bunch of "singleton tests" and studying the "plumbing commands" as they say, or stumbling upon one of the very few well-made tutorials which go just deep enough into the design to make you understand how it works without drowning you in it (I'm definitely not talking about official doc: it's on the same level as man: for some things, it's good enough, for others it's completely obscure).

Personally though, I don't mind. I mean, I've been infuriated a good deal at start, and there are still some behaviours that puzzle me sometimes...
But considering the raw power of the tool, I think spending a few couple hours on it is a very, very small price to pay (I'm probably using it at somewhere along 10% of all it can achieve and it already changed my life XD).
That does not mask the fact that Git is mind-blowing (in all meanings, especially the bad ones) tool to harness in the first times, and the power it brings also means you need both a clear collaboration model and people rigorous enough to follow it, otherwise it ends as a big mess (well, that proble is not Git-specific really, it's just enhanced).

uid313 I find it very intuitive. I've also spent about 2 hour learning it, but it was worth it and can do basically any common thing without even thinking about it.

Well, I have my answer. You're just full of it.
With 2 hours under your belt, you had enough to use Git for yourself. And for a solo developer, Git is a very very glorified multidimensional rsync.
Problems start arising, and complexity starts showing, when you use it for what it was conceived for, aka collaboration in polymorphic group of people (aka team varying in time, know-how and cultures).
It's then that you realize that while you thought you had understood, there are actually many things that escaped your grasp. XD

polarathene and others recommending GitKraken: could you please explain in what way it helps you? I gave it a (maybe too) quick try, but it didn't impress me much.
My two main gripes with Git are seeing the intertwining of branches (for which AFAIR it can't really help) and enforcing proper merge rules (for which it's easier to propagate a custom git configuration file to your team, or otherwise pointing out a README to check at all times).

To help my team understand Git, personally I used the following:
First, a custom hands-on training obviously. Then...
- https://www.cycligent.com/git-tool (specifically helps understand the flow of local work, obviously useless as a general tool)
- https://onlywei.github.io/explain-git-with-d3/ (great site to visually test basic use-cases)
- https://medium.freecodecamp.org/git-...s-a1e44e7ecafe (because you can't really understand git without understanding the storage).

Then I gave them this url (http://ndpsoftware.com/git-cheatsheet.html) to always have a quick reminder + a custom wiki with our collaboration guidelines and most used 'complex' commands (like a custom log command to display short commits in tree on command line)

Even like that, they are always veerry careful about any operation they make. XD

UX? Seriously, who the heck uses a GUI client for git? It's so much powerful from the command line.

Agreed, mostly. I'd dare make an audacious comparison and say it's like "find | " vs GUI indexation: sure, those got pretty functional over time, but nothing can ever beat imo a solid, acquired-through-efforts-and-tears knowledge of all those "basic" commands like find sed grep du and the piping/redirection mechanics.

Only limitations for me in command line are branches (I had found a script that generated a tree of just the branches, without commits, but didn't work well) and conflict resolution (that Git system is a fucking big mess, although to be fair I don't know how it could otherwise deal with conflicts... I'm sure seasoned developers have no problem with that kind of writing, I personally prefer checkout different versions to load them in a Meld or Kdiff although that method is clunky too ^^).

For the rest though? I wouldn't even know how to use a graphical tool to make specific operations like diff of one file among commits on different branches. Whereas in command it's a quick line (plus git diff is actually one of the few intuitive parts of git ^^). Same with getting the whole history of modifications applied to one particular file. This is the kind of greatness that makes you glad you spent time learning it (maybe it's a normal feature for any CVS, I don't know, never used one before git in a professional context). ^^

[abott]

Citan: You say all that garbage, yet everyone in software development uses it and disagrees. Troll yourself with that. You're worth less to an employer not being able to use basic tools you should be able to handle day-to-day without help for most of it. Have fun being you, using svn or whatever the fuck you think is nicer and does nice things, and oh yeah, sucks.

[Citan]

Citan: You say all that garbage, yet everyone in software development uses it and disagrees. Troll yourself with that. You're worth less to an employer not being able to use basic tools you should be able to handle day-to-day without help for most of it. Have fun being you, using svn or whatever the fuck you think is nicer and does nice things, and oh yeah, sucks.

abott Oh, nice troll. You didn't even bother reading it seems... Not that I expected anything else considering latest posts...

I mean, it's not like I said that I was using Git and liking it, but that didn't hide the fact there were completely anti-ergonomical choices... Oh wait!

Also, yeah, most people use it, it doesn't mean they fount it simple to grasp. Otherwise, why are there so many different tutorials to explain even the basic commands (including one of the best I could stumble upon which is based on explaining the underlying concepts)? Or dedicated threads ranting or explaining why it's complex yet worth using? -just picking a few random posts among a few thousands ^^
(Finally, just FYI, I never used svn so I had no preconceptions whatsoever. I do know a few things about human learning and ergonomics though)