11 ms·

Highlights from Git 2.35

258 points by ossusermivami 5y ago

rossmohax 5y ago
TIL there is a `--histogram` diff mode, producing more readable diffs.
- hoseja 5y ago
  TIL the reason Windows and Linux `long` are different is called "64-bit data model".
  - cesarb 5y ago
    If you want to learn more about it: - The reason the Unix world chose to have "long" as 64 bits: https://unix.org/version2/whatsnew/lp64_wp.html https://unix.org/version2/whatsnew/lp64_wp.html - The reason the Windows world chose to keep "long" as 32 bits: https://devblogs.microsoft.com/oldnewthing/20050131-00/?p=36563 https://devblogs.microsoft.com/oldnewthing/20050131-00/?p=36...
    - bvrmn 5y ago
      It's fascinating. Win chose LLP64 because pinned LONG to 32bit width in various format headers.
tomthecreator 5y ago
For anyone not using `merge.conflictStyle = diff3` I highly recommend trying it. It removes a lot of ambiguity when dealing with conflicting changes. And now they introduced `zdiff3` which looks even better, will be trying it once I update.
- rossmohax 5y ago
  I wonder why they introduced new diff mode, rather than making diff3 better.
  - steerablesafe 5y ago
    It's semantically slightly different. In the case of diff3 if you remove everything but the base part, then you get exactly the base version, while in the case of zdiff3 you also get the prefix and suffix parts from the two branches that merge cleanly. I guess the difference is subtle, especially that there can be other merges within the same file that merge cleanly in both cases.
  - hmate9 5y ago
    Some people are used it, prefer it and probably it would break some automated tests people have too.
    - thombat 5y ago
      Workflow: https://xkcd.com/1172/ https://xkcd.com/1172/
    - tester756 5y ago
      who cares? I hate this approach because this is very lazy (you avoid thinking about hard stuff and pick easy solution) and is very short term sure you can introduce 150 configuration modes but it makes your thing messy, confusing for new people, confusing for inexperienced and requires more maintenance it's like taking tech debt
      - junon 5y ago
        > who cares? Loads of people who have to maintain things.
      - Minor49er 5y ago
        This is a standard approach to software development: you introduce a new alternative for something that exists, then mark the existing inferior option as "deprecated". This gives developers a chance to learn about the new feature and move over to it by the time it actually gets removed in a future version. Cutting it immediately would cause a huge amount of frustration since the users of the feature would demand to know where it went or why it suddenly no longer works while the maintainers would have to scramble to find a solution. It would turn people off from using that software in the future.
- tome 5y ago
  > For anyone not using `merge.conflictStyle = diff3` I highly recommend trying it. It removes a lot of ambiguity when dealing with conflicting changes. Yes, and to say that another way, it's literally impossible to resolve merge conflicts correctly with only the standard conflict style. See my post on StackOverflow for more details: https://stackoverflow.com/a/63739655/997606 https://stackoverflow.com/a/63739655/997606
  - vlovich123 5y ago
    I use kdiff3 or bc4. I find those tools more powerful for fixing complicated merges and just as easy for simple ones (eg manual alignment for when the merge algorithm can’t recognize what is supposed to be aligned)
  - actually_a_dog 5y ago
    I’ve tripped over the exact scenario you mention in that post more than once. Usually, it’s not that I end up including an entire function that shouldn’t be there, though. I find it tends to be more like “Oh, here’s an extraneous bit of code that just showed up in the middle of this method. Hmmm....” Or, alternatively, I end up removing too much code, rather than too little.
- actually_a_dog 5y ago
  Yessssssssss! zdiff3 was by far the most exciting thing in the whole announcement for me. It’s a terrible feeling that comes over me when, not only do I get the pleasure of resolving a merge conflict, but I do it incorrectly, leading to a bad merge. Minimizing the amount of lines I have to consider when doing so seems like the most straightforward way to increase the accuracy of humans when resolving merge conflicts.
- Myrmornis 5y ago
  (plug) delta does special display of diff3 merge conflicts: https://github.com/dandavison/delta#merge-conflicts https://github.com/dandavison/delta#merge-conflicts It displays two diffs: one from the ancestral commit to “ours” and one from the ancestral commit to “theirs”. I find it helpful for understanding conflicts and how to resolve them — any feedback appreciated.
clktmr 5y ago
Finally there is `git stash --staged` and I can stop making temporary commits which I might forget about later and accidentially push.
- globular-toast 5y ago
  Woah, it didn't already? Magit has made that easy forever and I just assumed it was part of git at this point.
  - adamrt 5y ago
    Hah, I was thinking the same thing and jumped to comments to see if someone else mentioned it. I actually use this quite a bit in Magit. Magit is genuinely amazing. Thanks @tarsius!
    - tarsius 5y ago
      I usually try to leave the Magit praising to others in these threads but in this case I would have found it hard to resist. Glad others have already taken care of it. ;P
      - ashton314 5y ago
        You've made a thing that has many loyal users, myself included. :) Will this change make your work on Magit easier? If there was something you could add/remove to/from Git to make your life easier, what would it be?
        tarsius 5y ago
        It probably doesn't make much of a difference because Magit's stashing commands offer more flexibility that even after this addition is still missing from `git stash`. Stash creation is actually one of the very few areas where Magit doesn't use the respective Git procelain commands at all (as opposed to using them and then doing additional things using other pluming and/or porcelain commands as is the case in many other areas). Also I have to continue supporting older Git releases anyway; people like to use the latest Magit version without considering doing the same for Git, for some reason. Change the license to GPLv2 OR later.
politelemon 5y ago
The SSH signing feature is interesting as it can reduce the number of secrets I'm managing. Is my understanding correct that you'll also need the git hosting providers (Github, Gitlab) to understand and interpret those kinds of signed commits in order to show the 'verified' badge?
- ossusermivami 5y ago
  that's correct it's not currently supported on these platforms.
- bewuethr 5y ago
  In the official feedback discussions [1] from December 2021, the answer for this question was "won't start working on it for 2-4 months". [1]: https://github.com/github/feedback/discussions/7744#discussioncomment-1794438 https://github.com/github/feedback/discussions/7744#discussi...
chriswarbo 5y ago
Switching the diff algorithm to histogram is really useful when staging things selectively (via 'git add -p', Magit status buffer, etc.). For example, if we've inserted ABC and removed XYZ, we might want to put those in separate commits: insert ABC above XYZ, then remove XYZ. If the diff gets them the wrong way round (inserting ABC below XYZ), then we have to manually edit the patch. This is unavoidable in general, but fiddling with the options can reduce its occurrence. In particular, the default algorithm often spots exact matches like lines only containing '{', then comes up with really convoluted diffs in order to keep those braces matched up (often this will delete entire functions and add them all back!).
- avgcorrection 5y ago
  Thank you. I use interactive staging all the time with Magit so this might make a difference for my workflow.
capableweb 5y ago
Any reasons (beyond PR) that these highlights are posted on the blog of GitHub instead of on the main website of Git itself? Sadly, even Google is so confused about Git VS GitHub that searching for "git blog" shows github.blog as the first result...
- tngranados 5y ago
  Because they are written by a GitHub employee. If there were equivalent posts on the Git website, one could argue that we should link to those instead, but it is GitHub who writes and publish these posts and even if they are a form of PR, they are informative nevertheless.
- jasode 5y ago
  >Any reasons (beyond PR) that these highlights are posted on the blog of GitHub instead of on the main website of Git itself? Probably the most obvious reason is that author Taylor Blau is employed by Github. If Github funds his work on Git, it doesn't seem strange at all that he posts on his employer's website. Also, if you're referring to "git-scm.com" as the "main website of Git", there may be practical reasons such as TB not having any authoring privileges there to write a blog type of post. I notice that Git contributor Junio C Hamano who wrote the Git release notes doesn't post blog articles there either. JCH's blog-style posts seem to be at a different url: https://git-blame.blogspot.com/ https://git-blame.blogspot.com/ You didn't ask but a related question people wonder about is why HN users (such as ossusermivami in this thread's case) submit Github links more often than the Git mailing list release notes: https://news.ycombinator.com/item?id=28207811 https://news.ycombinator.com/item?id=28207811
  - williamdclt 5y ago
    > but a related question people wonder about is why HN users (such as ossusermivami in this thread's case) submit Github links more often than the Git mailing list release notes: I'd wager because it's more discoverable, more readable and contains very useful layman-readable explanations of what is going on in this release
OJFord 5y ago
Git jump is interesting, not new in this release (in 2.19) but I wasn't aware of it. I'm generally already in vim in another shell though, so I want the quickfix list populated there, not in a new instance. A while ago I wrote a vim plugin for this, has a bug where it (only sometimes?) won't go to the last conflict, but it's been helpful enough that I use it frequently. https://github.com/OJFord/vim-quickfix-conflicts https://github.com/OJFord/vim-quickfix-conflicts (Yes, shameless promotion/maybe bait someone more familiar with vimscript into using it and immediately spotting cause of the above!)
trulyrandom 5y ago
Does anyone know what the status is of the transition from SHA-1 to SHA-256?
- gbba 5y ago
  Still considered experimental in 2.35.0: https://git-scm.com/docs/git-init https://git-scm.com/docs/git-init
des429 5y ago
Am I the only one not seeing a `git jump` command in v2.35.0 installed via brew?
- ossusermivami 5y ago
  it's an extra script to install
Jeff_Brown 5y ago
Good grief git is big.
- geodel 5y ago
  Yeah, I was hoping some expert architects like Martin Fowler would provide blueprint of next generation Micro service architecture for git.
  - tex0 5y ago
    Not sure if you're joking or not ^^.
- fdeage 5y ago
  If you are interested in a code review of git architecture: https://fabiensanglard.net/git_code_review/index.php https://fabiensanglard.net/git_code_review/index.php
parentheses 5y ago
i love that github does this
yboris 5y ago
Am I the only one whose mind is blown that there is no official download I can click to install on Mac? https://git-scm.com/download/mac https://git-scm.com/download/mac I tried brew and it seems to have the old version; another download link gives me a 5-month-old version. Why is there no official click-to-install release?
- TheChaplain 5y ago
  The mac version doesn't have enough volunteers?
- js2 5y ago
  brew edit git That should open this in your editor: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/git.rb https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/... Change the url and sha256, then brew install git (This is from memory; I'm not in front of a shell, but I think it's correct.)
- dcchambers 5y ago
  It was updated in homebrew yesterday[1]. Your homebrew package index is probably just out of date. Run `brew update` to update all formulae. 11:15:43 ~ brew info git git: stable 2.35.0 (bottled), HEAD Distributed revision control system https://git-scm.com /usr/local/Cellar/git/2.34.1 (1,513 files, 42.7MB) * Poured from bottle on 2021-11-30 at 14:52:55 From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/git.rb License: GPL-2.0-only ... [1]: https://github.com/Homebrew/homebrew-core/blob/master/Formula/git.rb https://github.com/Homebrew/homebrew-core/blob/master/Formul...
arve0 5y ago
Anybody know if it’s possible to run a formater before diffing? For example running “go fmt” or “prettier”?
- TheChaplain 5y ago
  Wouldn't it be better to do that before committing? Or by using a hook? Since diff is used to make patches it could ruin things I imagine..
  - arve0 5y ago
    Yes, using a hook is optimal. But when reading repos without a style guide or formater, “pretty diffing” makes it easier to review. Another use case is when you encounter that giga god-commit “added formater” which touched all lines in all files. If you take this even further, you can tailor to anyones style taste, formatting on check out instead of check in. That leaves the stored code as a serialization format the compiler understands. Viewed code is in whatever format the programmer likes.
- 5e92cb50239222b 5y ago
  I haven't tested this, but maybe it will serve you as a starting point. Throw this script into $PATH (let's say into ~/.local/bin/diff-fmt): #!/bin/bash exec delta <(gofmt "$1") <(gofmt "$2") here I'm using delta as the difftool: https://github.com/dandavison/delta https://github.com/dandavison/delta and then, once: $ git config --global interactive.diffFilter diff-fmt
  - arve0 5y ago
    Thank you, will try it out :-)
tex0 5y ago
Is it only me or is git terribly complicated? How is average Joe (or rather: average coder) supposed to handle it correctly?
- highmastdon 5y ago
  What is your problem?
- Hackbraten 5y ago
  It’s not just you. Git is complicated. Some of the complexity is because of some bad UX decisions that were made early on. Those are difficult to undo. I’d recommend an average coder to practice, be patient, and not give up. I don’t think there’s a way around it. They’ll eventually get the hang of it, form a decent mental model, and eventually master the subcommands and switches they find most useful.

258 points by ossusermivami 5y ago

rossmohax 5y ago

TIL there is a `--histogram` diff mode, producing more readable diffs.

hoseja 5y ago
TIL the reason Windows and Linux `long` are different is called "64-bit data model".
- cesarb 5y ago
  If you want to learn more about it: - The reason the Unix world chose to have "long" as 64 bits: https://unix.org/version2/whatsnew/lp64_wp.html https://unix.org/version2/whatsnew/lp64_wp.html - The reason the Windows world chose to keep "long" as 32 bits: https://devblogs.microsoft.com/oldnewthing/20050131-00/?p=36563 https://devblogs.microsoft.com/oldnewthing/20050131-00/?p=36...
  - bvrmn 5y ago
    It's fascinating. Win chose LLP64 because pinned LONG to 32bit width in various format headers.

tomthecreator 5y ago

For anyone not using `merge.conflictStyle = diff3` I highly recommend trying it. It removes a lot of ambiguity when dealing with conflicting changes. And now they introduced `zdiff3` which looks even better, will be trying it once I update.

rossmohax 5y ago
I wonder why they introduced new diff mode, rather than making diff3 better.
- steerablesafe 5y ago
  It's semantically slightly different. In the case of diff3 if you remove everything but the base part, then you get exactly the base version, while in the case of zdiff3 you also get the prefix and suffix parts from the two branches that merge cleanly. I guess the difference is subtle, especially that there can be other merges within the same file that merge cleanly in both cases.
- hmate9 5y ago
  Some people are used it, prefer it and probably it would break some automated tests people have too.
  - thombat 5y ago
    Workflow: https://xkcd.com/1172/ https://xkcd.com/1172/
  - tester756 5y ago
    who cares? I hate this approach because this is very lazy (you avoid thinking about hard stuff and pick easy solution) and is very short term sure you can introduce 150 configuration modes but it makes your thing messy, confusing for new people, confusing for inexperienced and requires more maintenance it's like taking tech debt
    - junon 5y ago
      > who cares? Loads of people who have to maintain things.
    - Minor49er 5y ago
      This is a standard approach to software development: you introduce a new alternative for something that exists, then mark the existing inferior option as "deprecated". This gives developers a chance to learn about the new feature and move over to it by the time it actually gets removed in a future version. Cutting it immediately would cause a huge amount of frustration since the users of the feature would demand to know where it went or why it suddenly no longer works while the maintainers would have to scramble to find a solution. It would turn people off from using that software in the future.
tome 5y ago
> For anyone not using `merge.conflictStyle = diff3` I highly recommend trying it. It removes a lot of ambiguity when dealing with conflicting changes. Yes, and to say that another way, it's literally impossible to resolve merge conflicts correctly with only the standard conflict style. See my post on StackOverflow for more details: https://stackoverflow.com/a/63739655/997606 https://stackoverflow.com/a/63739655/997606
- vlovich123 5y ago
  I use kdiff3 or bc4. I find those tools more powerful for fixing complicated merges and just as easy for simple ones (eg manual alignment for when the merge algorithm can’t recognize what is supposed to be aligned)
- actually_a_dog 5y ago
  I’ve tripped over the exact scenario you mention in that post more than once. Usually, it’s not that I end up including an entire function that shouldn’t be there, though. I find it tends to be more like “Oh, here’s an extraneous bit of code that just showed up in the middle of this method. Hmmm....” Or, alternatively, I end up removing too much code, rather than too little.
actually_a_dog 5y ago
Yessssssssss! zdiff3 was by far the most exciting thing in the whole announcement for me. It’s a terrible feeling that comes over me when, not only do I get the pleasure of resolving a merge conflict, but I do it incorrectly, leading to a bad merge. Minimizing the amount of lines I have to consider when doing so seems like the most straightforward way to increase the accuracy of humans when resolving merge conflicts.
Myrmornis 5y ago
(plug) delta does special display of diff3 merge conflicts: https://github.com/dandavison/delta#merge-conflicts https://github.com/dandavison/delta#merge-conflicts It displays two diffs: one from the ancestral commit to “ours” and one from the ancestral commit to “theirs”. I find it helpful for understanding conflicts and how to resolve them — any feedback appreciated.

clktmr 5y ago

Finally there is `git stash --staged` and I can stop making temporary commits which I might forget about later and accidentially push.

globular-toast 5y ago
Woah, it didn't already? Magit has made that easy forever and I just assumed it was part of git at this point.
- adamrt 5y ago
  Hah, I was thinking the same thing and jumped to comments to see if someone else mentioned it. I actually use this quite a bit in Magit. Magit is genuinely amazing. Thanks @tarsius!
  - tarsius 5y ago
    I usually try to leave the Magit praising to others in these threads but in this case I would have found it hard to resist. Glad others have already taken care of it. ;P
    - ashton314 5y ago
      You've made a thing that has many loyal users, myself included. :) Will this change make your work on Magit easier? If there was something you could add/remove to/from Git to make your life easier, what would it be?
      - tarsius 5y ago
        It probably doesn't make much of a difference because Magit's stashing commands offer more flexibility that even after this addition is still missing from `git stash`. Stash creation is actually one of the very few areas where Magit doesn't use the respective Git procelain commands at all (as opposed to using them and then doing additional things using other pluming and/or porcelain commands as is the case in many other areas). Also I have to continue supporting older Git releases anyway; people like to use the latest Magit version without considering doing the same for Git, for some reason. Change the license to GPLv2 OR later.

politelemon 5y ago

The SSH signing feature is interesting as it can reduce the number of secrets I'm managing. Is my understanding correct that you'll also need the git hosting providers (Github, Gitlab) to understand and interpret those kinds of signed commits in order to show the 'verified' badge?

ossusermivami 5y ago
that's correct it's not currently supported on these platforms.
bewuethr 5y ago
In the official feedback discussions [1] from December 2021, the answer for this question was "won't start working on it for 2-4 months". [1]: https://github.com/github/feedback/discussions/7744#discussioncomment-1794438 https://github.com/github/feedback/discussions/7744#discussi...

chriswarbo 5y ago

Switching the diff algorithm to histogram is really useful when staging things selectively (via 'git add -p', Magit status buffer, etc.). For example, if we've inserted ABC and removed XYZ, we might want to put those in separate commits: insert ABC above XYZ, then remove XYZ. If the diff gets them the wrong way round (inserting ABC below XYZ), then we have to manually edit the patch. This is unavoidable in general, but fiddling with the options can reduce its occurrence. In particular, the default algorithm often spots exact matches like lines only containing '{', then comes up with really convoluted diffs in order to keep those braces matched up (often this will delete entire functions and add them all back!).

avgcorrection 5y ago
Thank you. I use interactive staging all the time with Magit so this might make a difference for my workflow.

capableweb 5y ago

Any reasons (beyond PR) that these highlights are posted on the blog of GitHub instead of on the main website of Git itself? Sadly, even Google is so confused about Git VS GitHub that searching for "git blog" shows github.blog as the first result...

tngranados 5y ago
Because they are written by a GitHub employee. If there were equivalent posts on the Git website, one could argue that we should link to those instead, but it is GitHub who writes and publish these posts and even if they are a form of PR, they are informative nevertheless.
jasode 5y ago
>Any reasons (beyond PR) that these highlights are posted on the blog of GitHub instead of on the main website of Git itself? Probably the most obvious reason is that author Taylor Blau is employed by Github. If Github funds his work on Git, it doesn't seem strange at all that he posts on his employer's website. Also, if you're referring to "git-scm.com" as the "main website of Git", there may be practical reasons such as TB not having any authoring privileges there to write a blog type of post. I notice that Git contributor Junio C Hamano who wrote the Git release notes doesn't post blog articles there either. JCH's blog-style posts seem to be at a different url: https://git-blame.blogspot.com/ https://git-blame.blogspot.com/ You didn't ask but a related question people wonder about is why HN users (such as ossusermivami in this thread's case) submit Github links more often than the Git mailing list release notes: https://news.ycombinator.com/item?id=28207811 https://news.ycombinator.com/item?id=28207811
- williamdclt 5y ago
  > but a related question people wonder about is why HN users (such as ossusermivami in this thread's case) submit Github links more often than the Git mailing list release notes: I'd wager because it's more discoverable, more readable and contains very useful layman-readable explanations of what is going on in this release

OJFord 5y ago

Git jump is interesting, not new in this release (in 2.19) but I wasn't aware of it. I'm generally already in vim in another shell though, so I want the quickfix list populated there, not in a new instance. A while ago I wrote a vim plugin for this, has a bug where it (only sometimes?) won't go to the last conflict, but it's been helpful enough that I use it frequently. https://github.com/OJFord/vim-quickfix-conflicts https://github.com/OJFord/vim-quickfix-conflicts (Yes, shameless promotion/maybe bait someone more familiar with vimscript into using it and immediately spotting cause of the above!)

trulyrandom 5y ago

Does anyone know what the status is of the transition from SHA-1 to SHA-256?

gbba 5y ago
Still considered experimental in 2.35.0: https://git-scm.com/docs/git-init https://git-scm.com/docs/git-init

des429 5y ago

Am I the only one not seeing a `git jump` command in v2.35.0 installed via brew?

ossusermivami 5y ago
it's an extra script to install

Jeff_Brown 5y ago

Good grief git is big.

geodel 5y ago
Yeah, I was hoping some expert architects like Martin Fowler would provide blueprint of next generation Micro service architecture for git.
- tex0 5y ago
  Not sure if you're joking or not ^^.
fdeage 5y ago
If you are interested in a code review of git architecture: https://fabiensanglard.net/git_code_review/index.php https://fabiensanglard.net/git_code_review/index.php

parentheses 5y ago

i love that github does this

yboris 5y ago

Am I the only one whose mind is blown that there is no official download I can click to install on Mac? https://git-scm.com/download/mac https://git-scm.com/download/mac I tried brew and it seems to have the old version; another download link gives me a 5-month-old version. Why is there no official click-to-install release?

TheChaplain 5y ago
The mac version doesn't have enough volunteers?
js2 5y ago
brew edit git That should open this in your editor: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/git.rb https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/... Change the url and sha256, then brew install git (This is from memory; I'm not in front of a shell, but I think it's correct.)
dcchambers 5y ago
It was updated in homebrew yesterday[1]. Your homebrew package index is probably just out of date. Run `brew update` to update all formulae. 11:15:43 ~ brew info git git: stable 2.35.0 (bottled), HEAD Distributed revision control system https://git-scm.com /usr/local/Cellar/git/2.34.1 (1,513 files, 42.7MB) * Poured from bottle on 2021-11-30 at 14:52:55 From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/git.rb License: GPL-2.0-only ... [1]: https://github.com/Homebrew/homebrew-core/blob/master/Formula/git.rb https://github.com/Homebrew/homebrew-core/blob/master/Formul...

arve0 5y ago

Anybody know if it’s possible to run a formater before diffing? For example running “go fmt” or “prettier”?

TheChaplain 5y ago
Wouldn't it be better to do that before committing? Or by using a hook? Since diff is used to make patches it could ruin things I imagine..
- arve0 5y ago
  Yes, using a hook is optimal. But when reading repos without a style guide or formater, “pretty diffing” makes it easier to review. Another use case is when you encounter that giga god-commit “added formater” which touched all lines in all files. If you take this even further, you can tailor to anyones style taste, formatting on check out instead of check in. That leaves the stored code as a serialization format the compiler understands. Viewed code is in whatever format the programmer likes.
5e92cb50239222b 5y ago
I haven't tested this, but maybe it will serve you as a starting point. Throw this script into $PATH (let's say into ~/.local/bin/diff-fmt): #!/bin/bash exec delta <(gofmt "$1") <(gofmt "$2") here I'm using delta as the difftool: https://github.com/dandavison/delta https://github.com/dandavison/delta and then, once: $ git config --global interactive.diffFilter diff-fmt
- arve0 5y ago
  Thank you, will try it out :-)

tex0 5y ago

Is it only me or is git terribly complicated? How is average Joe (or rather: average coder) supposed to handle it correctly?

highmastdon 5y ago
What is your problem?
Hackbraten 5y ago
It’s not just you. Git is complicated. Some of the complexity is because of some bad UX decisions that were made early on. Those are difficult to undo. I’d recommend an average coder to practice, be patient, and not give up. I don’t think there’s a way around it. They’ll eventually get the hang of it, form a decent mental model, and eventually master the subcommands and switches they find most useful.