Comment by pitaj
2 days ago
Some changes I would make:
1. Always use `git switch` instead of `git checkout`
2. Avoid `reset --hard` at all costs. So for the "accidentally committed something to master that should have been on a brand new branch" issue, I would do this instead:
# create a new branch from the current state of master
git branch some-new-branch-name
# switch to the previous commit
git switch -d HEAD~
# overwrite master branch to that commit instead
git switch -C master
# switch to the work branch you created
git switch some-new-branch-name
# your commit lives in this branch now :)
3. I'd apply the same to the `cherry-pick` version of "accidentally committed to the wrong branch":
git switch name-of-the-correct-branch
# grab the last commit to master
git cherry-pick master
# delete it from master
git switch -d master~
git switch -C master
4. And also to the "git-approved" way for "Fuck this noise, I give up.":
# get the lastest state of origin
git fetch origin
# reset tracked files
git restore -WS .
# delete untracked files and directories
git clean -d --force
# reset master to remote version
git switch -d origin/master
git switch -C master
# repeat for each borked branch
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:
The real "internal model" of git contains much more data/moving parts.
There isn't one tree of commits, there are typically at least two: local and remote
Branches are not just pointers to commits, but also possibly related to pointers in the other tree via tracking.
Stash and index and the actual contents of the working directory are additional data that live outside the tree of commits. When op says "avoid git reset hard" it's because of how all these interact.
Files can be tracked, untracked and ignored not ignored. All four combinations are possible.
None of these seem to preclude a command to make an arbitrary branch point to an arbitrary commit without changing anything else.
12 replies →
The "move a branch from one commit to another without changing anything" command is "git reset".
"git reset --hard" is "...and also change all the files in the working directory to match the new branch commit".
"git reset --soft" is "...but leave the working directory alone".
Actually, "git reset --soft" moves the current branch to another commit, without moving the index (aka staging area) along with it, whereas "git reset" (aka "git reset --mixed") moves the current branch AND the index to another commit. I really couldn't wrap my head around it before I had gone through "Reset demystified" [1] a couple times - it's not a quick read but I can strongly recommend it.
[1] https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified
git reset only works if you're on the branch you want to move, which is why every one of these example flows has you create your new branch, then do the reset, then switch to the new branch, instead of just allowing you to move a branch you're not on.
> 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
Something I heard somewhere that stuck with me: git is less less of a Version Control System, and more of a toolkit for assembling your own flavor of one.
> Something I heard somewhere that stuck with me: git is less less of a Version Control System, and more of a toolkit for assembling your own flavor of one.
That's how it is in principle, but it seems to me that there aren't that many different CLI "porcelains" in practice. Kind of like how Knuth figured people would essentially write their DSLs on top of plain TeX, not spend most of their time in giant macro packages like LaTeX.
1 reply →
I prefer just using `git switch` because it's easy to remember the flags (and the position of arguments), but you're right, there is a simpler way:
You should also be able to do
2 replies →
Good to know! Thanks for the tip.
Are there alternative git command lines that keep the beautiful internals, but implement a more elegant and intuitive set of commands to manage it?
Check out jujutsu or jj (same thing). It's its own VCS, but it uses git as a backend, so it works with GitHub and other git integrations
Another vote for jujutsu. No one else needs to know you're using it. You can think of it as just a different CLI for git (although you shouldn't mix them). I used to use third-party interfaces like lazygit, but I don't need them anymore because jujutsu _just makes sense_.
Seconded jujutsu. It's 100% git-compatible and one of those rare birds that is both more powerful and simpler to use in practice due to rethinking some of the core ideas.
Lazygit has a terminal UI but might otherwise be what you're looking for: https://github.com/jesseduffield/lazygit
The "move a branch" command is `git push .`. Yes, you can push to the current repo. I have a script called git-update-branch which just does some preflight checks and then runs `git push --no-verify . +$branch@{upstream}:$branch` to reset a branch back to its upstream version.
> The "move a branch" command is `git push .`. Yes, you can push to the current repo.
Wouldn't that copy a branch rather than moving it?
For move-branch: Use `git branch -f master HEAD~` if you're currently on another branch, or `git reset --soft HEAD~` if you're currently on master.
> 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 switch -C 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.
Learning about the `-p` option for `git add` was one of two things that revolutionized my Git usage. (The other was figuring out how to write effective commit messages.)
This is the main reason to use a GUI imho.
1 reply →
True enough, but it does make for good practice with the index and splitting workflows later on when you need to clean it up.
I think there's space for "git add ." as a didactic step. It maps cleanly to the most obvious way to understand a commit, as "here's what I've done". Bootstrapping from that to an understanding of "commits as communication with other developers" will naturally happen over time.
Is not very compatible with printlog-debugging. I'd rather encourage devs to prod around as they go if it benefits them, which causes grief for either them or reviewers in the end if they've internalized what you just said.
Explicitly adding internalizes a personal review process as inherent part of the push process, instead of something you attempt to force on top later.
It's better with a collaboration workflow that limits the span of time with expected discipline, imo.
3 replies →
Could you motivate why you suggest these? Why is `switch` better than `checkout`? And why not use `reset --hard`?
Not comment OP, but checkout has two very different uses merged into one: restoring files and switching branches. To not break compatibility, git has now switch and restore commands that make commands more readable and understandable.
You should avoid reset --hard because it will delete all your uncommited, and you could end up in situations where that's really bad. Using reset --keep will keep uncommited changes, and failing if any uncommited change cannot be kept.
I just do
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`?
It leaves behind tracked files that were moved or deleted between revisions.
> 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:
3. Move a commit from one branch to another.
4. Fuck this noise, I give up:
Bonus content, translated from the article:
> Oh shit, I committed and immediately realized I need to make one small change!
> Oh shit, I need to change the message on my last commit!
> Oh shit, I tried to run a diff but nothing happened?!
> Oh shit, I need to undo a commit from like 5 commits ago!
> Oh shit, I need to undo my changes to a file!
And finally there are a few things that are super easy/obvious in jujutsu that are far more annoying in git.
> Oh shit, I committed and many commits later realized I need to make one small change!
> Oh shit, I committed and many commits later realized I need to make extensive changes!
> Oh shit, I need to reorder two commits!
> Oh shit, I haven't committed anything in hours but I need something from an interim change from like thirty minutes ago
> Oh shit, I made a bunch of changes but want them to be in multiple commits (e.g., patch-add workflow)
> Oh shit, I need to break out a change from my current work into a new branch off master
> Oh shit, I need to make three sequential changes but roll them out one-by-one. I also might need to make fixes to previous ones before later ones are rolled out.
Please kindly write one for a jj-specific issue: "my build vomitted out a bunch of files and I used any jj command before editing my .gitignore"
I've found myself using git to fix the mess in this particular instance.
Alternatively if you have a bunch of files spewed everywhere with no rhyme or reason which can't be globbed or enumerated reasonably:
One thing I really appreciate is that you can run `jj new master` at _any_ time to drop what you're doing and start a new change. The way jj handles the working copy, conflicts, and visible heads means there's just no need to think about uncommitted changes, unfinished conflict resolution, detached head, etc.. So many things that would get in your way just can't happen.
I haven’t thought about it at all but you’re right. It’s surprising how nice it is that I can enter a repo and `jj new main` without needing to remember any context whatsoever.
My post was a pretty naked attempt to showcase how much less convoluted basic operations are in jj vs. git and hopefully drum up some interest. Hopefully someone bites.
2 replies →
git switch is too new and its man page says "THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."
millennial boomer here where is the gen z cheat sheet for this git switch thing that i keep hearing about
> 1. Always use `git switch` instead of `git checkout`
Even harder: always use "git reset --hard".
Basically don't use local branches. The correct workflow for almost every task these days is "all branches are remote". Fetch from remotes. Reset to whatever remote branch you want to work above. Do your work. Push back to a remote branch (usually a pull request branch in common usage) when you're done.
If you need to manage local state, do it manually with tags (or stash, but IMHO I never remember what I stashed and will always make a dummy commit and tag it).
Don't ever try to manually manage a branch locally unless you (1) absolutely have to and (2) absolutely know what you're doing. And even then, don't, just use a hosted upstream like github or whatever.
This sounds like the correct Git workflow if you think the correct VCS to use is SVN.
And that sounds like you failed to understand me. I didn't say "don't use branches". I said "all branches are remote". Pushing to a branch is communication with other human beings. Mixing your own private state into that is confusing and needless in 99% of situations (and the remaining 1% is isomorphic to "you're a maintainer curating branches for pushing to other people at a well-known location").
All branches are public.
3 replies →
This is a workflow I’ve never seen on any team or project I’ve worked on. Another commenter already mentioned the remote branch for everything preference, but usage of tags is especially interesting to me. I think that’s how most people use branches, and tags tend to be more permanent. What do you do when you come back to the commit with the tag, cherry pick it over and delete the tag? It sounds like an overly complicated process compared to having a branch and rebasing onto the current branch when you finally go to make the change for real.
Local branches aren't names for anything other humans beings care about. All "branches" discussed in a team are remote. But because branches have "history" and "state", keeping your local names around is just inviting them to get out of sync with identically or similarly-named branches out there in the rest of the world.
> It sounds like an overly complicated process compared to having a branch and rebasing onto the current branch when you finally go to make the change for real.
Not sure I understand the problem here? The rebase is the hard part. It doesn't help you to have a name for the code you're coming "from". If it collides it collides and you have to resolve it.
What I said about tags was just as short term memory "This commit right here worked on this date", stored in a way that (unless I delete or force-update the tag) I can't forget or pollute. Branches don't have that property. And again local branches don't have any advantages.
At first I was put aback by this, but it actually kinda makes sense. I mean, if people are giving off unwarranted advises about "the right way" here, yeah, you should start with a remote branch, and push all your work ASAP. Especially when you are closing the lid of your laptop to change location.
...Not that I am gonna follow that advice, of course. Same as I'm not gonna use git switch for a task git checkout does perfectly well.