• 1 Post
  • 9 Comments
Joined 1 year ago
cake
Cake day: July 22nd, 2023

help-circle

  • According to tab autocomplete…

    $ git
    zsh: do you wish to see all 141 possibilities (141 lines)?
    

    But what about the sub options?

    $ git clone https://github.com/git/git
    $ cd git/builtin
    # looking through source, options seem to be declared by OPT
    # except for if statements, OPT_END, bug checks, etc.
    $ grep -R OPT_ | grep --invert-match --count -E \
    "OPT_END|BUG_ON_OPT|if |PARSE_OPT|;$|struct|#define"
    1517
    

    Maybe 1500 or so?

    edit: Indeed, maybe this number is too low. git show has a huge amount of possibilities on its own, though some may be duplicates and rewords of others.

    $ git show --
    zsh: do you wish to see all 489 possibilities (163 lines)?
    $ man git-show | col -b | grep -E "^       -" --count
    98
    

    An attempt at naively parsing the manpages gives a larger number.

    $ man $(find /usr/share/man -name "git*") \
    | col -b | grep -E "^       -" -c 
    1849
    

    Numbers all over the place. I dunno.


  • Huh, TIL.

    To be fair, git switch was also derived from the features of git checkout in >2.23, but like git restore, the manual page warns that behavior may change, and neither are in my muscle memory (lmao).

    I’ll probably keep using checkout since it takes less kb in my head. Besides, we still have to use checkout for checking out a previous commit, even if I learn the more ergonomically appropriate switch and restore. No deprecation here so…

    edit: maybe I got that java 8 mindset

    edit 2: Correction – git switch --detach checks out previous commits. Git checkout may only be there for old scripts’ sake, since all of its features have been split off into those two new functions… so there’s nothing really keeping me from switch.


  • It probably is, but I think their main point is the protest against the age-old delineation into “GUI vs CLI” camps. I’m not saying that you’re elitist, even if your statement might be interpreted as such (it’s hard to communicate tone online but the quotations around “their workflow” could appear mocking), but regarding the structure of your statement, I had a “Windows users are all button-presser noobs” phase and would’ve typed something similar about the Git CLI if time was decently rewound (sans the kindness of a “use what you like” statement). They could be interpreting your statement as a propagation of the anti-GUI stereotyping.

    Evidently they prefer GUI but can effectively use the CLI – no one disagrees that the CLI is more functional.


  • Click to view diffs is super ergonomic; on the other hand, I actually have a story about the Git CLI trumping the GUI (spoiler: reflog).

    In high school we had gotten the funding to build a robot, and one of the adults in charge – guy was brilliant – was using GitHub Desktop to conduct a feature merge with the student who served as team lead. The thing was, he was used to older codebases, so all of his experience was with CVS instead of Git – so when the two slightly messed up the git merge, they discussed recloning everything instead of wasting time plumbing the error (relevant xkcd).

    That was one of the earliest times I had the cajones to walk up to a superior and say “No, you’re doing this totally wrong. You don’t have to do that.”

    He looked at me and nodded. “What would you do instead?”

    “Reflog.”

    “Reflog? I’ve never heard of it before. Can you show us?”

    I hopped onto the laptop and clicked around GitHub Desktop, but couldn’t manage to find any buttons related to reflog… so I went straight to cmd.exe instead.

    git reflog
    git reset --hard "HEAD@{7}"
    

    “Done. We can continue rebasing.”

    And after that, the advisor complimented me for using the command line tool!

    “Lots of GUI apps are just limited frontends to the real meat and potatoes, the command line. Nice job!”

    I felt like a wizard! And so I became the team’s Git-inator.

    edit: pruned story