what do you wish someone had told you about the Git command line interface when you started using Git for the first time? Especially curious about what you wish you'd known if you ended up choosing to use a IDE/GUI interface to Git.

(mostly interested in replies from people who started using Git in the last 5-10 years)

@b0rk use the 'git add' command to make commits selective.

@b0rk I've been using Git CLI for longer than 10 years.

Rebasing, squashing, reflog and worktrees. Most IDE/GUIs don't support or handle them well

@b0rk I wish I knew about `git add -p`. I only started using Git aggresively about ~10 years ago. I was previously a Mercurial guy.

@b0rk not directly CLI, git-rated shell prompt related:

The fact that git integrations for shells exist that tell you that you are "merging / cherry-picking / rebasing / bisecting" because I have way too often had the case that I didn't know some persistent state was still active.

Once I figured that out and started using such shell integration (and later built my own), working with git became much less confusing

@b0rk how important is to use "git add -p"

@b0rk mhm. I'm probably at the border of "started using in the last 10 year" also never considered IDE/GUI interface.

But probably one of the things which was bothering me in the beginning - not knowing anything about git stash and failing with git rebase :) Thus, poisoning my directory tree with multiple working-copies of stuff and losing my head between those.

@b0rk that complex commands (rebase) result in a cleaner history than simple commands (merge) and that the effort to learn them is worthwhile

@b0rk How much easier it is to edit the history, rebase, etc. from the command line

@b0rk I'd wish someone told my colleagues not to use Tortoise Git.

@b0rk as a teacher, the add on git fame has been life changing for summaries of who did what for projects. I got way more comfortable with the git command line after I started using that regularly, as I usually don't teach/require anything outside of clone/commit/push/pull for my classes.

@b0rk "you can use Mercurial instead and it's less confusing, more like svn. you just have to install the 'hg-git' plugin."

no, this wasn't 5-10 years ago, as my reference to svn indicates

@b0rk A commit message can be more than one line.

I started five years ago, and looking back this really escaped me in the beginning. Because as a noob, you know commit messages only as the thing that looks like a badly worded file description in a GitHub repo's default view.

Second thing would be: You don't have to add/commit all the files you changed at once. Often times it makes more sense to have a separate commit for e.g. updating the readme and the like.

@neal @b0rk i knew about it, but I didn’t understand hunks and staging and I found the language and UX inscrutable. I wish I understood it sooner.

@b0rk commits are forever; almost everything you can break is recoverable if you have the old commit IDs. Put them on screen before doing anything scary.

@b0rk most of this is fixed but legacy behavior is still supported and confusing for `git checkout`. `switch` and `restore` are *much* better but `checkout` still being there with its baroque usage for what are unrelated activities is problematic.

@b0rk .. the magic 'git rebase --onto ..' can do.

@b0rk "It's not personal, git has Opinions, hates everyone, and lurks in wait for an opportunity to exploit your mistakes for the lulz"

@b0rk rebase -i

@b0rk I wish I'd learned about stashing sooner

@b0rk You won't have to use it in a few years, because Jujutsu is git compatible and far more intuitive.

I was never terribly good at git, I'd say top 20th percentile of software devs but no higher, but ehh Jujutsu just makes it so much simpler.

@b0rk I use lazygit for anything complicated

@b0rk mostly about interactive stuff, like add --patch or rebase --interactive

also: branches are not what they seem to be. They're just movable tags on a huge commit tree, and not really separate from each other
After I realised this, it all clicked

@b0rk I wish I had known to use #Emacs's #magit interface.

@b0rk that you can autostash on pull. Whenever there's no conflict with local changes it's just way less annoying than an error message. Just the UX for resolving confligs (when applying stashes in general) is not great

@b0rk that knowing 4 or 5 commands is good enough 99%of the time.

@b0rk my best advice on git: use jj instead

@b0rk Git reset. That's still my absolute favorite command when I'm doing stuff that didn't work out - saves so much time when you'd otherwise have to commit a mess then commit a fix to the mess.

@b0rk probably filtering hunks by header

@b0rk "git stash -u" is much better to use than "git clean -f", as the stash command makes sure to log all changes and untracked files to a stash (so it's all tracked by git, in the reflog) before cleaning the changes from the file system.

In other words, it's a safe, undo-able alternative to clean.

@b0rk git stash list and git drop stash (forget correct command)

@b0rk Learning how the index works was crucial.
Having a good mental model for git is just as important.
Until I had that I was operating like this: https://xkcd.com/1597/

@b0rk I teach grad students that are new to Git, and their most common struggles are:

- understanding the commit messages are put in the whole repo, not just the pull request

- understanding that changing branches can make their files "go away" and that that is okay/expected

- understanding that being in feature branch 1 when creating feature branch 2 is not the same as being in main

- what makes a good commit message (but we all suffer from this)

@b0rk stop using any gui/tui. In case of commands: git add/checkout -p, git bisect -c, git reflog, … make it easier with git alias from omz/git plugin.

@b0rk `git log --oneline` : it's like reading a book ... when the commit messages are well writen though ^^

@b0rk That you can easily amend and extend commits you have not pushed yet. I went an embarrassingly long time not knowing that was possible.

@b0rk In my learning journey it took embarrassingly long until I discovered `git help revisions`.

Most of the other help pages expect you to know how to specify revisions or revision ranges, but none of them point you to the one place where it's explained. I could never remember things like how to get the second parent, or the second-level ancestor.

@b0rk that git is just a toy, I have no reason to be afraid of it and try to tame it, I could be focusing on my code instead 😌 that writing non-atomic commits with vague messages on my GUI is totally fine most of the time 🤸

@b0rk wtf did git threaten you make my children headless…

@b0rk learnt a bit more than ten years ago. But something like "take it easy, you will type the wrong command, cli is unintuitive as hell, but there is almost every time a way to clean the mess"

@b0rk
Command line only.
I never found any GUI as flexible.

@b0rk “don’t worry, it’s harder to actually lose work than you think”

@b0rk I learned Git using the CLI and I still work with it that way.

"Do not try to learn a set of commands and options associated. Understand the conceptual model and how the commands relate to it instead."

"The CLI is not the only way to use git, nor the best or the worse one. You can make sense of all of them by understanding the conceptual model."

My main interface today is magit, but I keep using the CLI somewhat regularly (e.g. when using someone else's machine).

Started using git in 2013, IIRC. No prior experience with a VCS.

@b0rk @brainwane 3 thoughts:

1) lots of people have trouble with“add” vs “commit” (to the extent GUI tools, esp. ones originally for svn or hg, often hide “add”), but I think that split is among git’s best features

2) experienced devs still get tangled beyond repair in rebase vs squash vs ff merge; I ❤️ rebase but am beginning to suspect my mental model is wrong

3) I know “git stash” is useful for more than briefly shelving my WIP while I glance at another branch, but I have no idea how

@b0rk -p and -v

@b0rk commit, add and push are 0.1% of the tool. It's real strength is in recovery through revert, cherry picking stash and soft resets, and from bisect. Bisect is a life saver so many times. Ow, and --interactive.

@b0rk I really expect nobody else will answer this, but: git hooks and git aliases. It is so, so much easier to instrument git from within its own execution processes than it is to try to wrap external control scripts around its interface. I had to do a _lot_ of this when the job duties that made me learn deep git in earnest involved a lot of wholesale history conversion from other version control tools.

I also wish someone had taught me how to drive `git fast-import` much earlier, ugh.

@b0rk @bagder I didn’t know about git init for about a year in the beginning, so I always used Github to create the repository then cloned it.

Also, the git difftool command can be configured to use any GUI diff application. Kaleidoscope is far and away the best Mac diff application. I wish there was one page where every dfftool config was listed

@b0rk There is no sequence of command line arguments in git to change to a new branch.

@seth what do you mean?

@b0rk That there's a safety net called reflog and I need not be afraid to mess something up.

@ellie @b0rk Same. Until I learned about "git reflog".

@b0rk I've been using git for more than 15 years.
Things I learned only in the last 5-10 years: git rebase -i (rebasing, amending commits, dropping commits etc.), git reflog (finding old heads)

@b0rk
Actually, someone told me to configure this alias, and it has been sooo useful:

[alias]
lola = log --graph --decorate --pretty=oneline --abbrev-commit --all

@b0rk "You don't have to understand it all at once. 4 commands will get you 90% of the way; just get started."

@b0rk `git diff -w` hides whitespace only lines. This means indenting blocks are less distracting.

@b0rk @brews understanding the mental model of git is more important than the question of prompt vs GUI

@b0rk @neal I still prefer git citool (GUI). It's horrible TCL/Tk stuff but it does the job.