Oh Shit, Git?

The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild. All of these recipes are unintuitive even if you have a firm grasp of git's model; you also need to know the quirks of the commands! To just look at the first one... wouldn't it be more intuitive for the command line interface to be:

    # this command exists already;
    $ git switch -c some-new-branch-name
    # is there a command that simply moves a branch from one commit to another without changing anything else? It feels like it should be possible given how git works.
    $ git move-branch master HEAD~

Not trying to defend the choice of `git checkout` over `git switch` (and `git restore`) but they were introduced in v2.23 of Git [0], which was released about 5 years ago [1]. If you take a look at their help pages, they still include a warning that says

> THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.

Granted, it has been in there for basically as long as the command(s) existed [2] and after 5 years perhaps it might be time to no longer call it experimental.

Still, it does seem like `git checkout` might be a bit more backwards compatible (and also reflective of the time when this website was originally created).

[0] https://github.com/git/git/blob/757161efcca150a9a96b312d9e78...

[1] https://github.com/git/git/releases/tag/v2.23.0

[2] https://github.com/git/git/commit/4e43b7ff1ea4b6f16b93a432b6...

5. Teaching `git add .` as default to add changes to the staging area is not ideal. Show adding specific files instead has less room for subsequent "oh shit" and better.

Could you motivate why you suggest these? Why is `switch` better than `checkout`? And why not use `reset --hard`?

What do you mean avoid "reset --hard"? Why or why is it not enough in practice? I use it quite often, along with "alias git-restore-file='git restore --source=HEAD --'". It seems to work.

What's the problem with `reset --hard`?

> 2. Avoid `reset --hard` at all costs

Sounds like you might be looking for `git reset --keep`

Rewriting these for jj users. I'm prefering long option names and full command names for clarity here, but all the commands have shortened aliases and all the option names have single-letter alternatives. `@` means "the current revision", `x+` means "the revision just after `x`", `x-` means "the revision just before `x`".

2. "Accidentally committed something to master that should have been on a brand new branch".

This doesn't really have an analogue. Branches ("bookmarks") only move when you tell them to. If you make a new commit on top of master, it doesn't point master to it, it just lives one past the tip of master. But let's say you accidentally moved master to include the new commit you shouldn't have:

    # set master to the previous commit (and reaffirm that
    # you're okay moving a bookmark backward)
    $ jj bookmark set master --allow-backwards --revision @- 

    # there is no step two, you're still editing the change you already were

    # move the revision one-past-master on to our desired bookmark
    $ jj rebase --revision master+ --destination name-of-the-correct-bookmark

    # there is also no step two; technically we're not updating the bookmark
    # to point to the new commit yet, but this isn't something you'd do as rote
    # habit in jujutsu anyway

    # list all the operations I've performed against the repo
    $ jj op log

    # restore to some previous known-good state
    $ jj op restore {id}

> Oh shit, I committed and immediately realized I need to make one small change!

    # move the current edits into the previous revision
    $ jj squash

    # re-describe the previous revision
    $ jj describe --revision @-

    # there is no staging area, all your changes are part of the repo and there is no
    # staging area pseudo-commit; please understand that this still works elegantly
    # with "patch-add" workflows and does not imply that large change sets can't be
    # easily broken up into small commits

    # find the commit
    $ jj log

    # back it out
    $ jj backout {id}

    # find the commit
    $ jj log

    # restore the paths provided to their contents in the given revision
    $ jj restore --from {id} [paths...]

> Oh shit, I committed and many commits later realized I need to make one small change!

    # moves the changes in the current working copy into the revision provided
    $ jj squash --into {id}

    # sets your working copy to the commit provided; later commits will be
    # auto-rebased on top live as you make modifications
    $ jj edit {id}

    # does what it says on the tin
    $ jj rebase --revision {a} --insert-before {b}

    # look in the "obsolete log" for earlier iterations of the current revision
    $ jj obslog

    # restore the contents
    $ jj restore --from {id} [paths...]

    # choose the parts to move out; you'll end up with two revisions, one with each half
    $ jj split

    # choose the parts to move out; you'll end up with two revisions, one with each half
    $ jj split

    # move the stuff I pulled out onto master
    $ jj rebase --revision @- --destination master

    # optional: name it; most of the time you wouldn't bother
    $ jj bookmark create new-name --revision master+

    # author a new change on top of master and name it a
    $ jj new master
    …
    $ jj bookmark create a

    # author a new change on top of a and name it b
    $ jj new
    …
    $ jj bookmark create b

    # author a new change on top of b and name it c
    $ jj new
    …
    $ jj bookmark create c

    # edit a; nothing else is necessary to ensure b and c remain as descendants of
    # revision a
    jj edit a
    …

    # author a new change as part of b; nothing else is necessary to ensure c remains
    # up to date on top of b
    $ jj new --insert-before c
    …

    # point c at the new change
    $ jj bookmark set b

Agreed that UIs generally provide a better UX for Git.

I use Magit and doing things like "abort cherry-pick" is discoverable in the interface itself and uses the exact same shortcut as the other "abort X" operations. If I had to use the Git CLI, I'd have no idea where to start.

Similarly, I've made mistakes in interactive rebases where I deleted a commit that shouldn't have been deleted. If I recall correctly, the start of every rebase creates a snapshot that is accessible from the reflog, so this is a safe way to revert changes from a rebase gone wrong. Magit's UI for the reflog is exactly the same as the UI for the log, so I was not lost when I saw it for the first time. With the Git CLI, I'd likely have no clue what's going on.

I've started recommending jj as a (git compatible) alternative to git, and one of the things I like about it is that the default action if you run `jj` with no arguments shows the relevant parts of the commit tree and where you are in it. This is a great reorientation tool, because you can see at a glance which commit you're working on right now, the branches and history associated with it, any other active branches in your repository, and for each you can see whether each commit had messages, changes associated with it, etc.

It's really powerful because it gives you precisely that visual layout that shows you what's going on in the repository, and what you're doing right now.

I advocate this with every newbie to git - find a UI that works for you and use it over the cli. Barely anyone listens though, and then they struggle with the cli and make a mess of their branches and fall out of date with main and are scared of rebasing and have many other issues that are solvable with a drag and drop or similar in a UI. I figure it's a sort of masochism.

> But first, people need to see visually how they can interact with the tree.

Interactive tutorial with tree visualization that has helped co-workers: https://learngitbranching.js.org/

I have not used such a tool in a long time, and never with git: but my past experience with GUI frontends for version control was that they work fine when everything is working fine, but once you have a mess to clean up, nobody can help you.

It has generally worked better for me to use the same interface everyone else is using, even when that interface is awful, because that eases communication with the rest of the team. It also lets me take advantage of online troubleshooting resources, which all assume you are doing things the normal way.

The cli is faster if you know by heart but a real disadvantage is that it is hard to "see" what you did or what happened in the past. Good look finding where/whether an old branch got merged and find out if it is part of a release, using cli.

GUI git clients are amazing in the hands of expert users, but terrible for any newcomer that has to actually use Git (and it's not like a designer checking out the source once or twice a month).

The gripe I have is that unless you expose people to CLIs early on, they will just not learn how to use a CLI at all. Whenever something inevitably breaks badly due to GUIs abstracting away how git really works in favour of a nicer UX, they'll end up asking someone that know Git how to fix their mess. And then, it's too late - they already know how to be productive-ish with git and how to deliver something. They can't justify investing time into learning the CLI (especially if they're not that great with Powershell or UNIX shells) so they constantly keep leaning on a colleague instead of learning.

This is not an hypothetical scenario - this really happened regularly at a place I worked at. Innumerable internal training lessons on Git went wasted due to people forgetting everything immediately by using Fork instead of the shell, and then pestering a handful of senior devs. Once IT banned Fork people were forced to use the terminal more often, so they had to learn how to use git for good and actually retained that knowledge via muscle memory.

The adage I've learnt over the course of the years is that the majority of people will go to any length to avoid learning new stuff. It's mentally less tiring to either waste their time doing stuff in an unproductive way than learning new things. IMHO it's better to force people to learn stuff the "right way" early on than let them pick up bad habits and then having to correct them later.

lazygit ! Just needed to throw out a mention because it’s an amazing tui for visual orientation, is super fast, and can be used with a mouse and keyboard (or just keyboard) from the terminal. I saw it mentioned on a thread here last year and have preferred it as a fast “oh crap I think I made a mess lets back up” tool over the more complex gui apps I’ve tried (almost all of them).

The GitHub effect is real, like all network effects, but that doesn't mean improvement is impossible. I've switched entirely to jj, and it having git compatibility means that I don't need to rely on anyone else to make that happen.

I am growing increasingly frustrated with various aspects of GitHub, and so I hope someday we all move past it too, but I don't think there's as simple of a path forward there.

SVN has always worked for me. You don’t have to “teach” people SVN because it’s intuitive and works just fine for the 99% case. I wish we would all stop larping as 1337 hackerz and just admit that git is overkill for the vast majority of people.

Any improvement will have to be git compatible at the very least, e.g. jj.

Both.

Manipulating complex trees via text is not easy, but the text UI is objectively bad:

https://stevelosh.com/blog/2013/04/git-koans/

It is the unquestioningly better tool right now. It's available, stable, battle-tested and it's actively supported. It's a case of "being the change you want to see". Just use it. Claims that it lost are counterproductive. The implicit deterrence from those statements is what is actively keeping Mercurial's adoption low.

Hosting is available at least from Sourcehut and heptapod.host.

I'm running a private Heptapod instance (Gitlab fork with direct Mercurial support). It just works.

That sounds interesting. Does anyone have a GitHub link?

It's the slower tool.

Modern scum (members of depraved modern culture) always prefer what is worse over what is better, so of course they prefer Git over Mercurial. Anyone who wants Mercurial hosting can use my hosting: https://hg.reactionary.software/

As everyone knows, though, Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.

Did you start with Git or have you used other VCS systems before? I started with SVN and then coming to Git, there were obviously things to learn about how it was different but honestly it felt to me like it made things easier in many ways (since I'd experienced the horror of a very large codebase in SVN with lots of branches, and trying to track those and merge back together - git is so much better at that, it's crazy)...

I can see how it would be a much bigger learning curve if people come straight to git, but it's still hard for me to understand where the blocker is that so many people complain about using it...

I was trying to delete a file from history yesterday.

The built in way (filter-branch) pops up a warning, with a long delay, saying you should hit Control+C and go download a third party python script called filter-repo...

It's ok mate. Hackernews says we should be using jj to manage our rewritten-in-Rust code.

I've been using Git for almost 15 years, and have twice built programs/products that use Git internally to achieve certain results (that is, the program/product itself uses Git for things, not just using Git to manage the source code for the program/product) and... sometimes before doing something a little gnarly in Git I'll still just do "cp -R .git ../git-backup" or something like that, so I can replace my entire .git dir with an older copy if I screw it up too bad. It's a ton faster than figuring out the right way to un-fuck any particular operation or set of operations.

This should be a built-in

  git unshit

  git add --unshit -f ~HEAD^^

You're not alone. https://xkcd.com/1597/

I have that with fstab

If I'm saving changes that were done because of a arduous debugging journey and other people are likely to have to refer back to it, yes. In fact, forget little; the smaller the change is, the bigger the text. Some of my changes have 2-3 paragraphs for a 2-3 line change because of the impact.

It seems painfully obvious to me that local and remote commits serve different purposes. Local commits are a way to create checkpoints when everything compiles and works and you can move on to the next step. That way you can stash your changes and go back to a working state when you screw things up. Then, before you push those changes, you reset them and split them into proper commits. That way the history is all nice and clean on the remote and it's not just a bunch of "wip"s.

Or you can just squash-merge your PRs and reap both benefits.

Commit is what causes git to make a copy of the file(s) internally. It's vitally important. But there is no point typing in silly messages like "more fixes" etc. What I do is make an initial commit with something like "(WIP) too feature", then keep doing amend commits until I'm happy, at which point I remove the "(WIP)" from the message.

>It's like saving a textfile. Do you write a little message every time you save a file? No that's silly. Just move on.

Do you write a little message about your day every time you go to sleep?

I actually don't, and maybe you don't, but plenty of people do.

I think of the Git revision log as much like that sort of diary, offering the same sorts of advantages. It's more organized than having a separate TODO list document; and it encourages you to describe what you've already done in a clear readable way, too. When you're trying to figure out how far to roll back, it may be useful to understand what you were thinking at the time of the commit. And if something turned out to be the wrong approach, it helps you do the post-mortem.

And, of course: if your unmerged, unpushed work is organized into separate changes that have separate (and labelled goals), and part of that work turns out to be good and part bad, it becomes vastly easier to preserve the good parts.

Well, it is all local until you push so you can do whatever you want.

With that said, it obviously is not meaningless at a technical level because without the commit there is nothing to push or merge. On top of that, at a non-technical level it can be extremely helpful to record some plain-english prose to describe why you are changing something. If you find yourself doing that too often you need to narrow your definition of what constitutes a "change" and/or be more discerning about what you work on simultaneously.

Out of curiosity, if you do not use git, what do you use for version control and change-management?

I actually use git for my todolist/diary and I have an alias for when I want to save which does git commit -m "whatever." Basically I do that so I can view the updated version in the mobile app.

If you memorize the documentation I suppose there's no problem with it, but even then there's confusing things from the beginning design approach.

Like, reset vs revert vs restore, using three similar starting synonyms for different operations.

Reset is particularly confusing because it sounds incredibly destructive, but if you do a soft 'git reset', it just moves the "changes to be committed" to be not staged for the commit.

Then, if you change a single flag (--hard) it is destructive, instead erasing all those changes from your disk.

And there's a reason nobody reads the docs, because they're laid out confusingly at first glance to an unfamiliar person.

If I go to git-scm.com, click docs, the first suggestion is the reference manual. The first guide is on "gitattributes" which gives no philosophy or context as to what it is even used for. Ok, maybe, I'll just check the complete list of git commands... and it starts talking about porcelain and plumbing. Nope, thats not what I need. Maybe try the link "git" under Setup and Config. There the description finally links to a useful "gittutorial" page.

The gittutorial even has some confusing or specific terminology that makes git seem hard. From the beginning of importing a new project "Assume you have a tarball project.tar.gz with your initial work"... why do we need to refer to tar at all, and it doesn't even do the credit of explaining the tar xzf command or what that tarball is. It could easily say 'assume you have a directory', which is the more common case and be 200% more simple.