17 ms·

Oh Shit, Git?

464 points by Anon84 2y ago

divbzero 2y ago
This is old school. No switch or restore here.
pitaj 2y 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
- lalaithion 2y ago
  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~
  - pitaj 2y ago
    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: git switch -c some-new-branch-name git branch -f master HEAD~
    - DangitBobby 2y ago
      You should also be able to do git branch -f master origin/master
      - pitaj 2y ago
        This doesn't work if your local master was already ahead of origin
        DangitBobby 2y ago
        Indeed, as with all of these examples exceptions will apply and, it's a good idea to check the log before taking any such action. I believe your example also depends on exactly how many commits you've made that need to be moved. In any case, it depends on me remembering exactly what `~` signifies.
    - lalaithion 2y ago
      Good to know! Thanks for the tip.
  - neild 2y ago
    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".
    - rav 2y ago
      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 https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified
- CharlieDigital 2y ago
  What's the problem with `reset --hard`?
  - pitaj 2y ago
    It leaves behind tracked files that were moved or deleted between revisions.
- mrshu 2y ago
  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/757161efcca150a9a96b312d9e780a071e601a03/Documentation/RelNotes/2.23.0.txt#L61-L65 https://github.com/git/git/blob/757161efcca150a9a96b312d9e78... [1] https://github.com/git/git/releases/tag/v2.23.0 https://github.com/git/git/releases/tag/v2.23.0 [2] https://github.com/git/git/commit/4e43b7ff1ea4b6f16b93a432b6718e9ab38749bd https://github.com/git/git/commit/4e43b7ff1ea4b6f16b93a432b6...
- baobun 2y ago
  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.
  - ajross 2y ago
    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.
    - baobun 2y ago
      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.
      - recursive 2y ago
        You can have both. Make sure the whole diff is what you want it to be before invoking `add .`
        baobun 2y ago
        Sure. I hear the pull-out method is also an effective contraceptive.
        recursive 2y ago
        If it works for you, I'm not going to try to talk you out of it.
- dustingetz 2y ago
  millennial boomer here where is the gen z cheat sheet for this git switch thing that i keep hearing about
- jaapz 2y ago
  Could you motivate why you suggest these? Why is `switch` better than `checkout`? And why not use `reset --hard`?
  - jopicornell 2y ago
    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.
    - teaearlgraycold 2y ago
      I just do git add -A git stash git reset --hard git stash pop
- stouset 2y ago
  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 3. Move a commit from one branch to another. # 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 4. Fuck this noise, I give up: # list all the operations I've performed against the repo $ jj op log # restore to some previous known-good state $ jj op restore {id} Bonus content, translated from the article: > Oh shit, I committed and immediately realized I need to make one small change! # move the current edits into the previous revision $ jj squash > Oh shit, I need to change the message on my last commit! # re-describe the previous revision $ jj describe --revision @- > Oh shit, I tried to run a diff but nothing happened?! # 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 > Oh shit, I need to undo a commit from like 5 commits ago! # find the commit $ jj log # back it out $ jj backout {id} > Oh shit, I need to undo my changes to a file! # find the commit $ jj log # restore the paths provided to their contents in the given revision $ jj restore --from {id} [paths...] 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! # moves the changes in the current working copy into the revision provided $ jj squash --into {id} > Oh shit, I committed and many commits later realized I need to make extensive changes! # sets your working copy to the commit provided; later commits will be # auto-rebased on top live as you make modifications $ jj edit {id} > Oh shit, I need to reorder two commits! # does what it says on the tin $ jj rebase --revision {a} --insert-before {b} > Oh shit, I haven't committed anything in hours but I need something from an interim change from like thirty minutes ago # look in the "obsolete log" for earlier iterations of the current revision $ jj obslog # restore the contents $ jj restore --from {id} [paths...] > Oh shit, I made a bunch of changes but want them to be in multiple commits (e.g., patch-add workflow) # choose the parts to move out; you'll end up with two revisions, one with each half $ jj split > Oh shit, I need to break out a change from my current work into a new branch off master # 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+ > 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. # 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
- ajross 2y ago
  > 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.
  - smrq 2y ago
    This sounds like the correct Git workflow if you think the correct VCS to use is SVN.
    - ajross 2y ago
      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.
      - ryandrake 2y ago
        I have quite a few projects that do not have a "remote" and will probably never have a remote repo. Should I not be using branches at all?
      - simoncion 2y ago
        > All branches are public. What actual problem does this solve? For me, WIP branches only ever get pushed up if at least one of two things are true about them: 1) They're actually worth preserving, and not some experimental garbage that ended up being totally pointless. 2) I need to get them off of my local machine for disaster-recovery purposes. > 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). I don't see the benefit one gets from putting work that's not fit for publication in a dummy commit on a public branch. That's just asking for garbage that noone should concern themselves with to accidentally get pushed up at the end of a long-ass day.
- johnisgood 2y ago
  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.
- Am4TIfIsER0ppos 2y ago
  git switch is too new and its man page says "THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."
- xk3 2y ago
  > 2. Avoid `reset --hard` at all costs Sounds like you might be looking for `git reset --keep`
  - deleted 2y ago
    [deleted]
behnamoh 2y ago
Git is one of those technologies that I never got to wrap my head around of, because in so many ways it doesn't follow intuition and unless you have been using it for a long time, for literally every action you would probably have to Google or use the man page of the command.
- nomel 2y ago
  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...
  - PaulDavisThe1st 2y ago
    Possibly consider that "deleting a file from history" is rather far outside the norm or recommended practice for git (even though it is, of course, entirely possible)
    - nomel 2y ago
      > even though it is, of course, entirely possible I take the more realistic perspective: until git makes it impossible to commit something that shouldn't have been, like a secret, then deleting a file from history is a fundamental requirement of git.
      - tom_ 2y ago
        The designers of git clearly disagreed, as you can guess from its design, so it's not surprising it might feel like a bit of an uphill struggle (and will probably remain so). There are other tools available.
        nomel 2y ago
        > The designers of git clearly disagreed filter-branch has been around since, at least, 1.8. It exists to rewrite history, this specific use case (as the official documentation details) included. An open source project admitting that a solution is better than their own does not mean the developers "disagree" with it, especially when the functionality has already been part of the developers tool for over a decade.
antithesis-nl 2y ago
Yeah, please don't create sites like this. Just... don't. Any, and I mean any "in case of a Git problem, just do this" recipe is wrong, often in very subtle ways. So, my advice: in case of a Git problem, contact the help channel provided by the organization hosting your Git repository. They'll help you out! And if it's your personal-I-am-truly-the-only-human-using-this repository? Just recreate it, and save yourself the pain. Source: I'm part of the team behind the #githelp channel in many $DAYJOBs, and we know how hard things are. You committed an unencrypted password file, or worse, your entire 'secret' MP4 collection to our monorepo? Sure, just let us know! Pushed your experimental branch to master/main/head/whatever? We'll fix it! Just don't ever, for whatever reason, run that-chain-of-commands you found on the Internet, without understanding what they do! In most cases, your initial mistake can be undone pretty quickly (despite requiring nonstandard tooling), but once you're three levels deep and four days later, not so much...
- 1over137 2y ago
  We’re not all working at $bigcorp with dedicated help teams. Sites like this are great and have helped me many times!
  - doubled112 2y ago
    What happens when you are the help team and it's the first time something goes wrong?
    - antithesis-nl 2y ago
      A 'team', by definition, consists of more people than 'you.' And, by the time a '#githelp team' is formed, it's to address patterns to which there are known solutions. One of the many problems with Git, is that these solutions depend very, very much on the structure of the repo and the common practices of its users. So, instead of executing random commands from the Internet, just ask. Please! Or, if there's truly nobody going to be around, give in and recreate the repo. You'll save yourself so much pain in the long run...
divbzero 2y ago
Previous discussions: Oh Shit, Git - https://news.ycombinator.com/item?id=31874308 https://news.ycombinator.com/item?id=31874308 - June 2022 (232 comments) Oh Shit Git? - https://news.ycombinator.com/item?id=24173238 https://news.ycombinator.com/item?id=24173238 - Aug 2020 (156 comments) Oh shit, git (2016) - https://news.ycombinator.com/item?id=19906972 https://news.ycombinator.com/item?id=19906972 - May 2019 (277 comments) Oh shit, git: Getting myself out of bad situations - https://news.ycombinator.com/item?id=15951825 https://news.ycombinator.com/item?id=15951825 - Dec 2017 (509 comments)
Rooster61 2y ago
Unable to access this. Might be hugged to death
- tonymet 2y ago
  https://archive.is/qXlY7 https://archive.is/qXlY7
fatih-erikli-cg 2y ago
[dead]
Retr0id 2y ago
my main use case for LLMs these days is asking it how to (un)do things with git
tantalor 2y ago
I'm not a git user, but stuff like this really drives home the idea that "git commit" is meaningless, the only thing that matters is when your commits are pushed or merged. 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.
- trashburger 2y ago
  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.
  - kstrauser 2y ago
    Same here. If it took me a week to figure out why to tweak a couple lines of code, I'm going to be explaining it. (Although also/mainly in the comments if it's something I worry someone might accidentally change back later.)
- shuntress 2y ago
  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?
- globular-toast 2y ago
  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.
tonymet 2y ago
github's "reflog" is the activity log API https://docs.github.com/en/rest/activity?apiVersion=2022-11-28 https://docs.github.com/en/rest/activity?apiVersion=2022-11-... Useful in case someone force-pushes and no one has the good ref locally.
SebastianKra 2y ago
We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.
- nuancebydefault 2y ago
  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.
  - harrall 2y ago
    Is this really true? When I want to reorder commits, I just drag & drop in a GUI and I’m done. Or if I want to switch branch or manage a complex mix of rebases or cherry picks, it’s just 2 or 3 clicks. In CLI, by the time I’ve typed out the commit hash or locator, it’s already taken longer. And I type 130 words per minute.
    - dijksterhuis 2y ago
      > by the time I’ve typed out the commit hash i don’t think i’ve typed out a full hash in … years? if i have i’ve used the short 8 character hash. git rev-parse might be something useful to have a look at, especially when combined with aliases.
      - harrall 2y ago
        Nah I’m talking about the short hash. But I still have to find the short hash too, and then copy or re-type it… With a UI, I just… click click click done.
- globular-toast 2y ago
  As a magit user I agree, apart from the fact most GUIs I've seen are horrendously broken and can lead to an even worse mess. For example, I was really confused about how a colleague messing up and got them to show me. Turns out in VS Code if you set the upstream branch correctly (ie. to master), it tries to get you to "sync" the branch. So it assumes the upstream branch is the branch you push to, which makes no sense at all.
franky47 2y ago
One of the beauties of Git is that as long as you’ve created an object, it’s impossible to lose that work (short of nuking the .git directory). Committing often is key. Precommit hooks (that take more than ~100ms) go against that.
- ge96 2y ago
  I have had git corruption problems on a raspberry pi sd card, usually I just had to reclone/abandon that folder
  - stephen_g 2y ago
    It honestly sounds like git is the least of your problems here...
    - ge96 2y ago
      yeah I can delete the .git folder and repull/add the remote origin, I had to do that again the other day. I'm not sure what it is, my SD card is a gold sandisk too not a cheapo.
- extraduder_ire 2y ago
  If you orphan the object by not having anything point to it, it goes away when "git gc" is run. That happens automatically after about two weeks by default. Even things like "git add" will create objects stored in the .git folder.
amelius 2y ago
This is why I run Git inside Git, as the latter allows me to undo anything I do within the former.
- CharlesW 2y ago
  As a Gitginner I'm wondering if this a good joke that went "wooooosh", or if this has something to do with submodules, or…?
  - shuntress 2y ago
    Git manages pretty much everything by using the `.git` folder created by `git init` and there is (as far as I am aware) nothing stopping you from going into that .git folder and running init again there to start using git to manage the internal state of your repository. At least... that is what I assumed the joke was.
- deadbunny 2y ago
  Literally `git reflog`
javier_e06 2y ago
Lately I've been asked to avoid merge-commits. They pollute the logs? If my push is blocked I am too far behind I create a new temp branch of master and do a "merge --squash" to it and then a "reset --hard" from temp branch back to my original branch. Heck sometimes I rather keep my changes in patches to void does darn merge CONFLICTS...specially when rebasing.
- a_t48 2y ago
  From memory... git merge origin/master git reset origin/master git commit -am "squash" # might need some extra fixup if your branch has added files No need to make a temp branch. I know there's probably a more efficient way of doing this, but this is what's stuck in my head.
- pitaj 2y ago
  Hard to understand exactly what your issue is here. Typically when people say "avoid merge commits" they mean they want you to almost always rebase instead of merge. Can you give an example or something?
- nuancebydefault 2y ago
  The thing is if you merge immediately into master and have conflicts, you solve the conflict and only then you can merge. But then the conflict resolution sits at the merge point with a weird default commit message and is hard to decipher. A nicer way is merge master into your branch, with the rebase option (you can set that option as the default). This will put your changes on top of the master changes that happened during populating your own branch. There you solve any conflicts and those usually immediately show you what happened in the meantime, making it easier to do so. The latest greatest now sits in your branch. Then as a plus, you can retest that merge and if necessary, fix the merge. Optionally you can do a pull request for reviewing. The diff the reviewers see is conflict-less and makes sense, has only your changes. Then simply merge to master, which should be trivial if you don't wait for long.
  - Nullabillity 2y ago
    Merge main into your branch, then merge --no-ff your branch into main. No need to rebase or squash anything.
daitangio 2y ago
I love this site, it helped me and it also funny. Kudos to the creator!
bitwrangler 2y ago
Other fun git hacks... * https://hackaday.com/2017/05/23/stupid-git-tricks/ https://hackaday.com/2017/05/23/stupid-git-tricks/ * https://ongardie.net/blog/sqlite-in-git/ https://ongardie.net/blog/sqlite-in-git/
grokx 2y ago
I can also recommend git flight rules: https://github.com/k88hudson/git-flight-rules https://github.com/k88hudson/git-flight-rules It saved my work a couple of times.
mfashby 2y ago
Related, you can get this as a nice printed zine https://jvns.ca/blog/2018/10/27/new-zine--oh-shit--git-/ https://jvns.ca/blog/2018/10/27/new-zine--oh-shit--git-/
deleted 2y ago
[deleted]
frakt0x90 2y ago
I'm not proud of it, but my #1 "Oh shit" git operation is to just delete my local repo, reclone, and reapply the changes. Works really well for me 95% of the time. The rest I ask dev ops guy to help.
- wruza 2y ago
  This should be a built-in git unshit Or git add --unshit -f ~HEAD^^ If you’re using git version <= 2.844.
  - maleldil 2y ago
    Jujutsu has `jj undo`, but which undoes whatever was your last jj command, regardless of what it was. It makes much more confident to do an operation I'm uncertain of. And if I regret something many actions down the line, you have `jj op log` (a better reflog).
    - zahlman 2y ago
      If you `jj undo` a second time, does it redo (undoing the undo), or does it back up another step?
      - steveklabnik 2y ago
        It redos, there's discussion about if and how this should change: https://github.com/jj-vcs/jj/issues/3700 https://github.com/jj-vcs/jj/issues/3700
        stouset 2y ago
        For background, this is because the `undo` itself is an operation pushed onto the top of the stack. It is a little counterintuitive.
    - blharr 2y ago
      Such a simple operation, but it'd probably fix 95% of problems I've had with git. "Uh oh, I tried to checkout a branch from remote by doing `git checkout origin/some-branch` instead of `git checkout some-branch` and made a couple source changes. Now I'm in detached head state. What is detached head ? I have to stash my revisions? Can I make a new branch with the same name or do I need to delete the origin/some-branch that I'm on?" When you could be able to just revert the "operation" and check out the correct branch, that's amazing.
philipwhiuk 2y ago
My hot take is that Git isn't nearly as hard as the endless blogs pretend.
- reaperducer 2y ago
  Git is a technology that was invented to simplify things that ended up getting so complex over time that an entire industry started up around it to try to make it simple again. See also: Docker. Probably lots of others.
  - globular-toast 2y ago
    Actually, no. Git was a technology invented specifically to enable Linux kernel development. It hasn't become any more complex since its inception. The problem is most people aren't doing kernel development and have absolutely no idea what a distributed version control system is, yet they use git, a distributed version control system. I have no idea why we use it, to be honest, but I'm very glad that we do because the previous options were crap. Perhaps Mercurial is better, but git is good enough.
    - adamc 2y ago
      We were using svn before Git and easy cloning (and then PRs) has solved a LOT of problems. There are definitely still some things left to improve, though.
- tester756 2y ago
  "hard"? it is not hard, it is just poorly designed, the API (commands) are really terrible. Think of it: one person who cares about UX decades ago could make git 10 times more sane for milions of devs.
- deleted 2y ago
  [deleted]
- jeppester 2y ago
  I'm happy I didn't have to scroll too far to see this. Git's CLI isn't elegant, but it really isn't that big of a deal if you understand the basics of what a commit is, what a branch is etc. I struggle to understand why so many devs decide to treat it like mysterious arcane sorcery instead of just spending the needed time on learning how it works. The same can be said about regexes. Regexes and git are probably the two tools which I have benefitted the most from learning compared to how little time I've spend on learning them - and I wouldn't even consider myself an expert on either.
ioncannon 2y ago
Hey I worked with the person who made this! She did a fun presentation for our company.
codazoda 2y ago
Is this related to "Oh Shit, git?" by Julia Evans? https://wizardzines.com/zines/oh-shit-git/ https://wizardzines.com/zines/oh-shit-git/ Perhaps not and the authors just named it the same because it rolls off the tongue nicely.
- jvns 2y ago
  Yes! Katie and I made it into a zine because I was such a huge fan of her work on https://ohshitgit.com/ https://ohshitgit.com/. (you'll notice she's a coauthor of the zine)
globular-toast 2y ago
The one thing I wish people would internalise about git is it's an append only data store. To get work into the store, you commit it. Once in the store there is not a command in git that can remove it. This is how the reflog works. Whatever you do, you can get back to a previous branch state and restore the work from the data store. But git can't help you if you don't commit. So just commit. Commit all the time. If you think it's too much overhead and you always forget to commit, fix your tools. If you're writing code all day you should be committing at a minimum every hour, in general.
phtrivier 2y ago
This will feel very weird in April 2025, when we celebrate the 20th anniversary of git. I was there. And at some point I wondered if I should learn git, darcs, or bazaar, to replace SVN or CVS. Or did I try mercurial too ? I wonder if the "GitHub" effect has basically killed the need for a newcomer in the space of VCS. Maybe at some point, the yak is shaved enough ?
- jimbob45 2y ago
  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.
  - dasil003 2y ago
    svn is perfectly fine and intuitive as long as you never want to branch and merge
    - bear8642 2y ago
      huh? Svn can branch and merge - maybe bit more clunky but still works
  - grandiego 2y ago
    I agree with your sentiment. I was kind of "forced" to use (and eventually fully migrate to) git because the IDE integration to SVN became more quirky every year. Instead, git is already integrated in IDEs these days.
  - WorldMaker 2y ago
    Starting a new repo in SVN is find a server somewhere, if doesn't have SVN install SVN, if it does have SVN deal with whatever politics runs its trunk to find space/define a branch structure for you, and so forth. It is its own footgun as well, but with git you can git init any directory you want and have a repo. Other than the learning curve of the not particularly well tuned CLI (and there are all sorts of graphical clients today and alternative CLI clients), it's very low barrier to entry to get something/anything in source control. It's not just "larping as leet hackerz", there are real benefits to git over SVN. There are fewer barriers to entry for small teams and hobby devs, especially in a world with GitHub/GitLab/Sourcehut/and more, but also in the world where maybe a git repo never syncs with any other single machine or is hosted on the barest feature set SAMBA folder or is only ever using email-based PR flows. git could be easier to teach. git could have a better out of the box CLI. That doesn't mean "git is overkill" especially from the point of view of "needing a whole central server setup just to store multiple versions of a file is overkill". Git is perhaps "underkill", it does the bare minimum as best it can in whatever environment you give it. It's intentionally dumb and stupid (hence its name, to be fair) and it's learning curve is as much because it is "too dumb" than because it "isn't intuitive". I've seen some "intuitive" UIs built on top of it. Another comment here remarked "git isn't a source control system, it's a low level toolkit for building your own" and that's not far from the truth and definitely not far from git's origins (and its name). That's a sort of "underkill". ("One day we'll finally build the right, intuitive high level API." That's basically how git was designed. You don't have to just take my word on that, you can search the old mailing lists for all sorts of interesting discussions and debates on "porcelain" options.)
acombandrew 2y ago
this is good but is extremely reddit
- bartekpacia 2y ago
  hm, interesting - what does “reddit” mean when used as an adjective? (genuinely interested)
julienb_sea 2y ago
Oh shit, I accidentally `git reset HEAD~1` and moved the last commit to file diffs, which was a merge to master, and my file diff now is both the last branch merge and everything I've done in the last 8hrs. I did this once and it was a gigantic PITA to undo, if anyone has any hot tips for that particular idiocy...
- Am4TIfIsER0ppos 2y ago
  `git reset` again to move to the right commit
bradhe 2y ago
Love that the very first thing mentions reflog, arguably the most confusing and complicated git feature. The rest are good though.
argentinian 2y ago
I believe I have a good mental model of what git does, but I never remember commands' arguments to use when they are moderately complex. I mean that the commands are not discoverable or easy to memorize. I don't know if that's because the text UI is bad, or because it's simply difficult to explain with text what to do to manipulate a tree.
- stackghost 2y ago
  Both. Manipulating complex trees via text is not easy, but the text UI is objectively bad: https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/
gootz 2y ago
Pro tip: Sometimes it's easier to rewrite you're entire app rather than wrestle with git commands. /s
GianFabien 2y ago
Reading these tips confirms that I'm too stoopid to use git. Fortunately, I don't have to use git. So I just store work-in-progress as time-stamped files. Storage is cheap and plentiful. Can always diff, cherry pick, etc without confusing myself.
dgfitz 2y ago
I’m pumped a search for hg+mercurial had hits in this thread. I am and will continue to be completely blown that hg lost the dvcs wars. It’s a better tool.
- gmueckl 2y ago
  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.
  - greazy 2y ago
    Are there any public forges that support hg?
    - gmueckl 2y ago
      Have a look at heptapost.host for paid hosting and foss.heptapod.net for free public hosting for OSS. Is that what you are looking for?
    - romaniitedomum 2y ago
      > Are there any public forges that support hg? Sourceforge, Sourcehut, and GNU Savannah all support Mercurial.
  - dgfitz 2y ago
    I use it every day!
- paulddraper 2y ago
  It's the slower tool.
  - 2y ago
jaitaiwan 2y ago
I swear there used to be a choose your own adventure version of this where you could answer questions about what you did wrong and get a step-by-step "here's what to do" after.
- zargon 2y ago
  Perhaps it was this one? https://sethrobertson.github.io/GitFixUm/fixup.html https://sethrobertson.github.io/GitFixUm/fixup.html
felipeerias 2y ago
For a developer, one of the most useful things that LLMs can do is help out with Git issues. It really says something about the design and documentation of a tool when you need a (far more complex and energy-intensive) Artificial Intelligence to be able to use it without making too many mistakes.
margaretdouglas 2y ago
I force pushed over origin/master from a very not-up-to-date feature branch and don't have the remote history I overwrote fetched locally.
sagarpatil 2y ago
I just use cursor agent to do git now (unless it’s simple stuff)
kuringganteng 2y ago
[flagged]
sundarurfriend 2y ago
Silly comment, but: Every time I see `git reflog`, I see it as re-flog. It's possible that's even the reason I never remember the command, I subconsciously can't bring myself to think of it as "reference log". Instead, it's asking git to sell something cheaply, again.
- yonatan8070 2y ago
  I have that with fstab
  - dgfitz 2y ago
    It will always be f-stab in my head, can’t undo.
kmoser 2y ago
> Only amend commits that only exist in your local copy or you're gonna have a bad time. "Gonna have a bad time?" I really wish things like this were explained in more detail, rather than with glib warnings that are unhelpful unless you already know what they mean.
- extraduder_ire 2y ago
  The commit you're amending doesn't exist on your copy anymore, despite existing on the remote that you've pushed to. Warnings about detaching the HEAD in git are so common that they're kind of assumed to be basic knowledge to a lot of people. Explaining why it's bad if you don't already know would take quite a while too. I do wish git had some form of warning before you rewrite history that's been pushed somewhere. It should already have all the data to know that.
upghost 2y ago
Before learning magit on emacs, this site saved my ass so many times. After learning magit on emacs, this site saved my ass so many times.
- blharr 2y ago
  It used to save my ass a lot. It still does, but it used to, too.
  - dgfitz 2y ago
    Miss that guy.
meinersbur 2y ago
Avoid `git reset --hard` and `git clean -xfd`. To get a clean working-tree, use `git stash --all`. Allows restoring files if necessary. Saved my sorry bottom multiple times.
user4511 2y ago
Oh how I wish more devs would just read the documentation for the tools they pick. I read the git documentation end-to-end. Never really had any issues with it and most commands feels natural to use.
- blharr 2y ago
  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.
hkgjjgjfjfjfjf 2y ago
[dead]
scudsworth 2y ago
8 years of posting this

464 points by Anon84 2y ago

This is old school. No switch or restore here.

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

lalaithion 2y ago
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~
- pitaj 2y ago
  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: git switch -c some-new-branch-name git branch -f master HEAD~
  - DangitBobby 2y ago
    You should also be able to do git branch -f master origin/master
    - pitaj 2y ago
      This doesn't work if your local master was already ahead of origin
      - DangitBobby 2y ago
        Indeed, as with all of these examples exceptions will apply and, it's a good idea to check the log before taking any such action. I believe your example also depends on exactly how many commits you've made that need to be moved. In any case, it depends on me remembering exactly what `~` signifies.
  - lalaithion 2y ago
    Good to know! Thanks for the tip.
- neild 2y ago
  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".
  - rav 2y ago
    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 https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified
CharlieDigital 2y ago
What's the problem with `reset --hard`?
- pitaj 2y ago
  It leaves behind tracked files that were moved or deleted between revisions.
mrshu 2y ago
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/757161efcca150a9a96b312d9e780a071e601a03/Documentation/RelNotes/2.23.0.txt#L61-L65 https://github.com/git/git/blob/757161efcca150a9a96b312d9e78... [1] https://github.com/git/git/releases/tag/v2.23.0 https://github.com/git/git/releases/tag/v2.23.0 [2] https://github.com/git/git/commit/4e43b7ff1ea4b6f16b93a432b6718e9ab38749bd https://github.com/git/git/commit/4e43b7ff1ea4b6f16b93a432b6...
baobun 2y ago
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.
- ajross 2y ago
  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.
  - baobun 2y ago
    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.
    - recursive 2y ago
      You can have both. Make sure the whole diff is what you want it to be before invoking `add .`
      - baobun 2y ago
        Sure. I hear the pull-out method is also an effective contraceptive.
        recursive 2y ago
        If it works for you, I'm not going to try to talk you out of it.
dustingetz 2y ago
millennial boomer here where is the gen z cheat sheet for this git switch thing that i keep hearing about
jaapz 2y ago
Could you motivate why you suggest these? Why is `switch` better than `checkout`? And why not use `reset --hard`?
- jopicornell 2y ago
  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.
  - teaearlgraycold 2y ago
    I just do git add -A git stash git reset --hard git stash pop
stouset 2y ago
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 3. Move a commit from one branch to another. # 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 4. Fuck this noise, I give up: # list all the operations I've performed against the repo $ jj op log # restore to some previous known-good state $ jj op restore {id} Bonus content, translated from the article: > Oh shit, I committed and immediately realized I need to make one small change! # move the current edits into the previous revision $ jj squash > Oh shit, I need to change the message on my last commit! # re-describe the previous revision $ jj describe --revision @- > Oh shit, I tried to run a diff but nothing happened?! # 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 > Oh shit, I need to undo a commit from like 5 commits ago! # find the commit $ jj log # back it out $ jj backout {id} > Oh shit, I need to undo my changes to a file! # find the commit $ jj log # restore the paths provided to their contents in the given revision $ jj restore --from {id} [paths...] 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! # moves the changes in the current working copy into the revision provided $ jj squash --into {id} > Oh shit, I committed and many commits later realized I need to make extensive changes! # sets your working copy to the commit provided; later commits will be # auto-rebased on top live as you make modifications $ jj edit {id} > Oh shit, I need to reorder two commits! # does what it says on the tin $ jj rebase --revision {a} --insert-before {b} > Oh shit, I haven't committed anything in hours but I need something from an interim change from like thirty minutes ago # look in the "obsolete log" for earlier iterations of the current revision $ jj obslog # restore the contents $ jj restore --from {id} [paths...] > Oh shit, I made a bunch of changes but want them to be in multiple commits (e.g., patch-add workflow) # choose the parts to move out; you'll end up with two revisions, one with each half $ jj split > Oh shit, I need to break out a change from my current work into a new branch off master # 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+ > 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. # 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
ajross 2y ago
> 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.
- smrq 2y ago
  This sounds like the correct Git workflow if you think the correct VCS to use is SVN.
  - ajross 2y ago
    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.
    - ryandrake 2y ago
      I have quite a few projects that do not have a "remote" and will probably never have a remote repo. Should I not be using branches at all?
    - simoncion 2y ago
      > All branches are public. What actual problem does this solve? For me, WIP branches only ever get pushed up if at least one of two things are true about them: 1) They're actually worth preserving, and not some experimental garbage that ended up being totally pointless. 2) I need to get them off of my local machine for disaster-recovery purposes. > 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). I don't see the benefit one gets from putting work that's not fit for publication in a dummy commit on a public branch. That's just asking for garbage that noone should concern themselves with to accidentally get pushed up at the end of a long-ass day.
johnisgood 2y ago
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.
Am4TIfIsER0ppos 2y ago
git switch is too new and its man page says "THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."
xk3 2y ago
> 2. Avoid `reset --hard` at all costs Sounds like you might be looking for `git reset --keep`
- deleted 2y ago
  [deleted]

behnamoh 2y ago

Git is one of those technologies that I never got to wrap my head around of, because in so many ways it doesn't follow intuition and unless you have been using it for a long time, for literally every action you would probably have to Google or use the man page of the command.

nomel 2y ago
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...
- PaulDavisThe1st 2y ago
  Possibly consider that "deleting a file from history" is rather far outside the norm or recommended practice for git (even though it is, of course, entirely possible)
  - nomel 2y ago
    > even though it is, of course, entirely possible I take the more realistic perspective: until git makes it impossible to commit something that shouldn't have been, like a secret, then deleting a file from history is a fundamental requirement of git.
    - tom_ 2y ago
      The designers of git clearly disagreed, as you can guess from its design, so it's not surprising it might feel like a bit of an uphill struggle (and will probably remain so). There are other tools available.
      - nomel 2y ago
        > The designers of git clearly disagreed filter-branch has been around since, at least, 1.8. It exists to rewrite history, this specific use case (as the official documentation details) included. An open source project admitting that a solution is better than their own does not mean the developers "disagree" with it, especially when the functionality has already been part of the developers tool for over a decade.

antithesis-nl 2y ago

Yeah, please don't create sites like this. Just... don't. Any, and I mean any "in case of a Git problem, just do this" recipe is wrong, often in very subtle ways. So, my advice: in case of a Git problem, contact the help channel provided by the organization hosting your Git repository. They'll help you out! And if it's your personal-I-am-truly-the-only-human-using-this repository? Just recreate it, and save yourself the pain. Source: I'm part of the team behind the #githelp channel in many $DAYJOBs, and we know how hard things are. You committed an unencrypted password file, or worse, your entire 'secret' MP4 collection to our monorepo? Sure, just let us know! Pushed your experimental branch to master/main/head/whatever? We'll fix it! Just don't ever, for whatever reason, run that-chain-of-commands you found on the Internet, without understanding what they do! In most cases, your initial mistake can be undone pretty quickly (despite requiring nonstandard tooling), but once you're three levels deep and four days later, not so much...

1over137 2y ago
We’re not all working at $bigcorp with dedicated help teams. Sites like this are great and have helped me many times!
- doubled112 2y ago
  What happens when you are the help team and it's the first time something goes wrong?
  - antithesis-nl 2y ago
    A 'team', by definition, consists of more people than 'you.' And, by the time a '#githelp team' is formed, it's to address patterns to which there are known solutions. One of the many problems with Git, is that these solutions depend very, very much on the structure of the repo and the common practices of its users. So, instead of executing random commands from the Internet, just ask. Please! Or, if there's truly nobody going to be around, give in and recreate the repo. You'll save yourself so much pain in the long run...

divbzero 2y ago

Previous discussions: Oh Shit, Git - https://news.ycombinator.com/item?id=31874308 https://news.ycombinator.com/item?id=31874308 - June 2022 (232 comments) Oh Shit Git? - https://news.ycombinator.com/item?id=24173238 https://news.ycombinator.com/item?id=24173238 - Aug 2020 (156 comments) Oh shit, git (2016) - https://news.ycombinator.com/item?id=19906972 https://news.ycombinator.com/item?id=19906972 - May 2019 (277 comments) Oh shit, git: Getting myself out of bad situations - https://news.ycombinator.com/item?id=15951825 https://news.ycombinator.com/item?id=15951825 - Dec 2017 (509 comments)

Rooster61 2y ago

Unable to access this. Might be hugged to death

tonymet 2y ago
https://archive.is/qXlY7 https://archive.is/qXlY7

fatih-erikli-cg 2y ago

[dead]

Retr0id 2y ago

my main use case for LLMs these days is asking it how to (un)do things with git

tantalor 2y ago

I'm not a git user, but stuff like this really drives home the idea that "git commit" is meaningless, the only thing that matters is when your commits are pushed or merged. 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.

trashburger 2y ago
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.
- kstrauser 2y ago
  Same here. If it took me a week to figure out why to tweak a couple lines of code, I'm going to be explaining it. (Although also/mainly in the comments if it's something I worry someone might accidentally change back later.)
shuntress 2y ago
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?
globular-toast 2y ago
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.

tonymet 2y ago

github's "reflog" is the activity log API https://docs.github.com/en/rest/activity?apiVersion=2022-11-28 https://docs.github.com/en/rest/activity?apiVersion=2022-11-... Useful in case someone force-pushes and no one has the good ref locally.

SebastianKra 2y ago

We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.

nuancebydefault 2y ago
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.
- harrall 2y ago
  Is this really true? When I want to reorder commits, I just drag & drop in a GUI and I’m done. Or if I want to switch branch or manage a complex mix of rebases or cherry picks, it’s just 2 or 3 clicks. In CLI, by the time I’ve typed out the commit hash or locator, it’s already taken longer. And I type 130 words per minute.
  - dijksterhuis 2y ago
    > by the time I’ve typed out the commit hash i don’t think i’ve typed out a full hash in … years? if i have i’ve used the short 8 character hash. git rev-parse might be something useful to have a look at, especially when combined with aliases.
    - harrall 2y ago
      Nah I’m talking about the short hash. But I still have to find the short hash too, and then copy or re-type it… With a UI, I just… click click click done.
globular-toast 2y ago
As a magit user I agree, apart from the fact most GUIs I've seen are horrendously broken and can lead to an even worse mess. For example, I was really confused about how a colleague messing up and got them to show me. Turns out in VS Code if you set the upstream branch correctly (ie. to master), it tries to get you to "sync" the branch. So it assumes the upstream branch is the branch you push to, which makes no sense at all.

franky47 2y ago

One of the beauties of Git is that as long as you’ve created an object, it’s impossible to lose that work (short of nuking the .git directory). Committing often is key. Precommit hooks (that take more than ~100ms) go against that.

ge96 2y ago
I have had git corruption problems on a raspberry pi sd card, usually I just had to reclone/abandon that folder
- stephen_g 2y ago
  It honestly sounds like git is the least of your problems here...
  - ge96 2y ago
    yeah I can delete the .git folder and repull/add the remote origin, I had to do that again the other day. I'm not sure what it is, my SD card is a gold sandisk too not a cheapo.
extraduder_ire 2y ago
If you orphan the object by not having anything point to it, it goes away when "git gc" is run. That happens automatically after about two weeks by default. Even things like "git add" will create objects stored in the .git folder.

amelius 2y ago

This is why I run Git inside Git, as the latter allows me to undo anything I do within the former.

CharlesW 2y ago
As a Gitginner I'm wondering if this a good joke that went "wooooosh", or if this has something to do with submodules, or…?
- shuntress 2y ago
  Git manages pretty much everything by using the `.git` folder created by `git init` and there is (as far as I am aware) nothing stopping you from going into that .git folder and running init again there to start using git to manage the internal state of your repository. At least... that is what I assumed the joke was.
deadbunny 2y ago
Literally `git reflog`

javier_e06 2y ago

Lately I've been asked to avoid merge-commits. They pollute the logs? If my push is blocked I am too far behind I create a new temp branch of master and do a "merge --squash" to it and then a "reset --hard" from temp branch back to my original branch. Heck sometimes I rather keep my changes in patches to void does darn merge CONFLICTS...specially when rebasing.

a_t48 2y ago
From memory... git merge origin/master git reset origin/master git commit -am "squash" # might need some extra fixup if your branch has added files No need to make a temp branch. I know there's probably a more efficient way of doing this, but this is what's stuck in my head.
pitaj 2y ago
Hard to understand exactly what your issue is here. Typically when people say "avoid merge commits" they mean they want you to almost always rebase instead of merge. Can you give an example or something?
nuancebydefault 2y ago
The thing is if you merge immediately into master and have conflicts, you solve the conflict and only then you can merge. But then the conflict resolution sits at the merge point with a weird default commit message and is hard to decipher. A nicer way is merge master into your branch, with the rebase option (you can set that option as the default). This will put your changes on top of the master changes that happened during populating your own branch. There you solve any conflicts and those usually immediately show you what happened in the meantime, making it easier to do so. The latest greatest now sits in your branch. Then as a plus, you can retest that merge and if necessary, fix the merge. Optionally you can do a pull request for reviewing. The diff the reviewers see is conflict-less and makes sense, has only your changes. Then simply merge to master, which should be trivial if you don't wait for long.
- Nullabillity 2y ago
  Merge main into your branch, then merge --no-ff your branch into main. No need to rebase or squash anything.

daitangio 2y ago

I love this site, it helped me and it also funny. Kudos to the creator!

bitwrangler 2y ago

Other fun git hacks... * https://hackaday.com/2017/05/23/stupid-git-tricks/ https://hackaday.com/2017/05/23/stupid-git-tricks/ * https://ongardie.net/blog/sqlite-in-git/ https://ongardie.net/blog/sqlite-in-git/

grokx 2y ago

I can also recommend git flight rules: https://github.com/k88hudson/git-flight-rules https://github.com/k88hudson/git-flight-rules It saved my work a couple of times.

mfashby 2y ago

Related, you can get this as a nice printed zine https://jvns.ca/blog/2018/10/27/new-zine--oh-shit--git-/ https://jvns.ca/blog/2018/10/27/new-zine--oh-shit--git-/

deleted 2y ago

[deleted]

frakt0x90 2y ago

I'm not proud of it, but my #1 "Oh shit" git operation is to just delete my local repo, reclone, and reapply the changes. Works really well for me 95% of the time. The rest I ask dev ops guy to help.

wruza 2y ago
This should be a built-in git unshit Or git add --unshit -f ~HEAD^^ If you’re using git version <= 2.844.
- maleldil 2y ago
  Jujutsu has `jj undo`, but which undoes whatever was your last jj command, regardless of what it was. It makes much more confident to do an operation I'm uncertain of. And if I regret something many actions down the line, you have `jj op log` (a better reflog).
  - zahlman 2y ago
    If you `jj undo` a second time, does it redo (undoing the undo), or does it back up another step?
    - steveklabnik 2y ago
      It redos, there's discussion about if and how this should change: https://github.com/jj-vcs/jj/issues/3700 https://github.com/jj-vcs/jj/issues/3700
      - stouset 2y ago
        For background, this is because the `undo` itself is an operation pushed onto the top of the stack. It is a little counterintuitive.
  - blharr 2y ago
    Such a simple operation, but it'd probably fix 95% of problems I've had with git. "Uh oh, I tried to checkout a branch from remote by doing `git checkout origin/some-branch` instead of `git checkout some-branch` and made a couple source changes. Now I'm in detached head state. What is detached head ? I have to stash my revisions? Can I make a new branch with the same name or do I need to delete the origin/some-branch that I'm on?" When you could be able to just revert the "operation" and check out the correct branch, that's amazing.

philipwhiuk 2y ago

My hot take is that Git isn't nearly as hard as the endless blogs pretend.

reaperducer 2y ago
Git is a technology that was invented to simplify things that ended up getting so complex over time that an entire industry started up around it to try to make it simple again. See also: Docker. Probably lots of others.
- globular-toast 2y ago
  Actually, no. Git was a technology invented specifically to enable Linux kernel development. It hasn't become any more complex since its inception. The problem is most people aren't doing kernel development and have absolutely no idea what a distributed version control system is, yet they use git, a distributed version control system. I have no idea why we use it, to be honest, but I'm very glad that we do because the previous options were crap. Perhaps Mercurial is better, but git is good enough.
  - adamc 2y ago
    We were using svn before Git and easy cloning (and then PRs) has solved a LOT of problems. There are definitely still some things left to improve, though.
tester756 2y ago
"hard"? it is not hard, it is just poorly designed, the API (commands) are really terrible. Think of it: one person who cares about UX decades ago could make git 10 times more sane for milions of devs.
deleted 2y ago
[deleted]
jeppester 2y ago
I'm happy I didn't have to scroll too far to see this. Git's CLI isn't elegant, but it really isn't that big of a deal if you understand the basics of what a commit is, what a branch is etc. I struggle to understand why so many devs decide to treat it like mysterious arcane sorcery instead of just spending the needed time on learning how it works. The same can be said about regexes. Regexes and git are probably the two tools which I have benefitted the most from learning compared to how little time I've spend on learning them - and I wouldn't even consider myself an expert on either.

ioncannon 2y ago

Hey I worked with the person who made this! She did a fun presentation for our company.

codazoda 2y ago

Is this related to "Oh Shit, git?" by Julia Evans? https://wizardzines.com/zines/oh-shit-git/ https://wizardzines.com/zines/oh-shit-git/ Perhaps not and the authors just named it the same because it rolls off the tongue nicely.

jvns 2y ago
Yes! Katie and I made it into a zine because I was such a huge fan of her work on https://ohshitgit.com/ https://ohshitgit.com/. (you'll notice she's a coauthor of the zine)

globular-toast 2y ago

The one thing I wish people would internalise about git is it's an append only data store. To get work into the store, you commit it. Once in the store there is not a command in git that can remove it. This is how the reflog works. Whatever you do, you can get back to a previous branch state and restore the work from the data store. But git can't help you if you don't commit. So just commit. Commit all the time. If you think it's too much overhead and you always forget to commit, fix your tools. If you're writing code all day you should be committing at a minimum every hour, in general.

phtrivier 2y ago

This will feel very weird in April 2025, when we celebrate the 20th anniversary of git. I was there. And at some point I wondered if I should learn git, darcs, or bazaar, to replace SVN or CVS. Or did I try mercurial too ? I wonder if the "GitHub" effect has basically killed the need for a newcomer in the space of VCS. Maybe at some point, the yak is shaved enough ?

jimbob45 2y ago
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.
- dasil003 2y ago
  svn is perfectly fine and intuitive as long as you never want to branch and merge
  - bear8642 2y ago
    huh? Svn can branch and merge - maybe bit more clunky but still works
- grandiego 2y ago
  I agree with your sentiment. I was kind of "forced" to use (and eventually fully migrate to) git because the IDE integration to SVN became more quirky every year. Instead, git is already integrated in IDEs these days.
- WorldMaker 2y ago
  Starting a new repo in SVN is find a server somewhere, if doesn't have SVN install SVN, if it does have SVN deal with whatever politics runs its trunk to find space/define a branch structure for you, and so forth. It is its own footgun as well, but with git you can git init any directory you want and have a repo. Other than the learning curve of the not particularly well tuned CLI (and there are all sorts of graphical clients today and alternative CLI clients), it's very low barrier to entry to get something/anything in source control. It's not just "larping as leet hackerz", there are real benefits to git over SVN. There are fewer barriers to entry for small teams and hobby devs, especially in a world with GitHub/GitLab/Sourcehut/and more, but also in the world where maybe a git repo never syncs with any other single machine or is hosted on the barest feature set SAMBA folder or is only ever using email-based PR flows. git could be easier to teach. git could have a better out of the box CLI. That doesn't mean "git is overkill" especially from the point of view of "needing a whole central server setup just to store multiple versions of a file is overkill". Git is perhaps "underkill", it does the bare minimum as best it can in whatever environment you give it. It's intentionally dumb and stupid (hence its name, to be fair) and it's learning curve is as much because it is "too dumb" than because it "isn't intuitive". I've seen some "intuitive" UIs built on top of it. Another comment here remarked "git isn't a source control system, it's a low level toolkit for building your own" and that's not far from the truth and definitely not far from git's origins (and its name). That's a sort of "underkill". ("One day we'll finally build the right, intuitive high level API." That's basically how git was designed. You don't have to just take my word on that, you can search the old mailing lists for all sorts of interesting discussions and debates on "porcelain" options.)

acombandrew 2y ago

this is good but is extremely reddit

bartekpacia 2y ago
hm, interesting - what does “reddit” mean when used as an adjective? (genuinely interested)

julienb_sea 2y ago

Oh shit, I accidentally `git reset HEAD~1` and moved the last commit to file diffs, which was a merge to master, and my file diff now is both the last branch merge and everything I've done in the last 8hrs. I did this once and it was a gigantic PITA to undo, if anyone has any hot tips for that particular idiocy...

Am4TIfIsER0ppos 2y ago
`git reset` again to move to the right commit

bradhe 2y ago

Love that the very first thing mentions reflog, arguably the most confusing and complicated git feature. The rest are good though.

argentinian 2y ago

I believe I have a good mental model of what git does, but I never remember commands' arguments to use when they are moderately complex. I mean that the commands are not discoverable or easy to memorize. I don't know if that's because the text UI is bad, or because it's simply difficult to explain with text what to do to manipulate a tree.

stackghost 2y ago
Both. Manipulating complex trees via text is not easy, but the text UI is objectively bad: https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/

gootz 2y ago

Pro tip: Sometimes it's easier to rewrite you're entire app rather than wrestle with git commands. /s

GianFabien 2y ago

Reading these tips confirms that I'm too stoopid to use git. Fortunately, I don't have to use git. So I just store work-in-progress as time-stamped files. Storage is cheap and plentiful. Can always diff, cherry pick, etc without confusing myself.

dgfitz 2y ago

I’m pumped a search for hg+mercurial had hits in this thread. I am and will continue to be completely blown that hg lost the dvcs wars. It’s a better tool.

gmueckl 2y ago
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.
- greazy 2y ago
  Are there any public forges that support hg?
  - gmueckl 2y ago
    Have a look at heptapost.host for paid hosting and foss.heptapod.net for free public hosting for OSS. Is that what you are looking for?
  - romaniitedomum 2y ago
    > Are there any public forges that support hg? Sourceforge, Sourcehut, and GNU Savannah all support Mercurial.
- dgfitz 2y ago
  I use it every day!
paulddraper 2y ago
It's the slower tool.
- 2y ago

jaitaiwan 2y ago

I swear there used to be a choose your own adventure version of this where you could answer questions about what you did wrong and get a step-by-step "here's what to do" after.

zargon 2y ago
Perhaps it was this one? https://sethrobertson.github.io/GitFixUm/fixup.html https://sethrobertson.github.io/GitFixUm/fixup.html

felipeerias 2y ago

For a developer, one of the most useful things that LLMs can do is help out with Git issues. It really says something about the design and documentation of a tool when you need a (far more complex and energy-intensive) Artificial Intelligence to be able to use it without making too many mistakes.

margaretdouglas 2y ago

I force pushed over origin/master from a very not-up-to-date feature branch and don't have the remote history I overwrote fetched locally.

sagarpatil 2y ago

I just use cursor agent to do git now (unless it’s simple stuff)

kuringganteng 2y ago

[flagged]

sundarurfriend 2y ago

Silly comment, but: Every time I see `git reflog`, I see it as re-flog. It's possible that's even the reason I never remember the command, I subconsciously can't bring myself to think of it as "reference log". Instead, it's asking git to sell something cheaply, again.

yonatan8070 2y ago
I have that with fstab
- dgfitz 2y ago
  It will always be f-stab in my head, can’t undo.

kmoser 2y ago

> Only amend commits that only exist in your local copy or you're gonna have a bad time. "Gonna have a bad time?" I really wish things like this were explained in more detail, rather than with glib warnings that are unhelpful unless you already know what they mean.

extraduder_ire 2y ago
The commit you're amending doesn't exist on your copy anymore, despite existing on the remote that you've pushed to. Warnings about detaching the HEAD in git are so common that they're kind of assumed to be basic knowledge to a lot of people. Explaining why it's bad if you don't already know would take quite a while too. I do wish git had some form of warning before you rewrite history that's been pushed somewhere. It should already have all the data to know that.

upghost 2y ago

Before learning magit on emacs, this site saved my ass so many times. After learning magit on emacs, this site saved my ass so many times.

blharr 2y ago
It used to save my ass a lot. It still does, but it used to, too.
- dgfitz 2y ago
  Miss that guy.

meinersbur 2y ago

Avoid `git reset --hard` and `git clean -xfd`. To get a clean working-tree, use `git stash --all`. Allows restoring files if necessary. Saved my sorry bottom multiple times.

user4511 2y ago

Oh how I wish more devs would just read the documentation for the tools they pick. I read the git documentation end-to-end. Never really had any issues with it and most commands feels natural to use.

blharr 2y ago
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.

hkgjjgjfjfjfjf 2y ago

[dead]

scudsworth 2y ago

8 years of posting this