[HN Gopher] Oh Shit, Git?
___________________________________________________________________
Oh Shit, Git?
Author : Anon84
Score : 201 points
Date : 2025-01-16 18:24 UTC (4 hours ago)
(HTM) web link (ohshitgit.com)
(TXT) w3m dump (ohshitgit.com)
| divbzero wrote:
| This is old school. No switch or restore here.
| pitaj wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| You should also be able to do git branch -f
| master origin/master
| pitaj wrote:
| This doesn't work if your local master was already ahead
| of origin
| DangitBobby wrote:
| 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 wrote:
| Good to know! Thanks for the tip.
| neild wrote:
| 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 wrote:
| 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
| lalaithion wrote:
| 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.
| rav wrote:
| 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.
| Certhas wrote:
| 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.
| lalaithion wrote:
| None of these seem to preclude a command to make an
| arbitrary branch point to an arbitrary commit without
| changing anything else.
| fragmede wrote:
| This works if the branch exists or creates it if it
| doesn't exist, but not if it's checked out.
| git branch -f branch_name commit
|
| if it's checked out: git reset --hard
| commit
| jimbokun wrote:
| Are there alternative git command lines that keep the
| beautiful internals, but implement a more elegant and
| intuitive set of commands to manage it?
| dalia-reds wrote:
| 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
| stouset wrote:
| 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.
| Terr_ wrote:
| > 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.
| lilyball wrote:
| 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.
| CharlieDigital wrote:
| What's the problem with `reset --hard`?
| pitaj wrote:
| It leaves behind tracked files that were moved or deleted
| between revisions.
| mrshu wrote:
| 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...
| baobun wrote:
| 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.
| jaapz wrote:
| Could you motivate why you suggest these? Why is `switch`
| better than `checkout`? And why not use `reset --hard`?
| stouset wrote:
| Rewriting these for jj users. I'm prefering long option names
| and full command names, but all the commands have shortened
| aliases and all the option names have single-letter
| alternatives. `@` means "the current change", `x+` means "the
| change just after `x`", `x-` means "the change 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 change 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}
| dustingetz wrote:
| millennial boomer here where is the gen z cheat sheet for this
| git switch thing that i keep hearing about
| behnamoh wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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_ wrote:
| 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.
| lcnPylGDnU4H9OF wrote:
| Even if you purge the history, the secret is compromised
| and you should stop using it. It's moot whether or not
| you're able to remove it from history.
| bitwize wrote:
| It's ok mate. Hackernews says we should be using jj to manage
| our rewritten-in-Rust code.
| behnamoh wrote:
| Haha, I'm so glad I didn't fall for the whole rust thing.
| stouset wrote:
| Both you and GP, please aim higher for comments on HN.
| iimblack wrote:
| Since you brought it up, I personally switched to jujutsu and
| prefer it greatly. I regularly help coworkers deal with
| issues in git and keep dropping hints like `in jujutsu this
| would've been done way easier like this!`. Nobody bites yet
| since I think most of them don't want to use the CLI but
| maybe someday if enough people keep talking about it the
| inertia will get to the point that we can get some really
| slick GUIs for jj.
| dmd wrote:
| As everyone knows, though, Git gets easier once you understand
| branches are homeomorphic endofunctors mapping submanifolds of
| a Hilbert space.
| wbl wrote:
| That's the Darcs joke and you told it somewhat incorrectly.
| behnamoh wrote:
| Oh geez now that clarifies everything, how could I miss that?
| jimbokun wrote:
| > homeomorphic endofunctors mapping submanifolds of a Hilbert
| space
|
| Has to be easier to understand that then all the arbitrary
| git commands.
| sampo wrote:
| Git commands, while they may be cryptic, actually mean
| something. Whereas that was just gibberish made by putting
| random mathematical words together.
|
| (There is a similar sounding joke about category theory, "A
| monad is just a monoid in the category of endofunctors" but
| this sentence has a mathematical meaning.)
| antithesis-nl wrote:
| 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 wrote:
| We're not all working at $bigcorp with dedicated help teams.
| Sites like this are great and have helped me many times!
| doubled112 wrote:
| What happens when you are the help team and it's the first
| time something goes wrong?
| antithesis-nl wrote:
| 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...
| recursive wrote:
| > A 'team', by definition, consists of more people than
| 'you.'
|
| I'm the resident git expert, but not by choice. There's
| more that I don't know than that I do. It's not uncommon
| that I need to use internet recipes to un-wedge someone's
| clone.
|
| > 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...
|
| This is insane. There are a dozen other people using the
| remote, not to mention a whole CI/CD build configuration.
| antithesis-nl wrote:
| OK, so you've truly screwed up your your personal/small-team
| repos to the point of requiring poorly-understood command
| sequences from the Notoriously Reliable Internet more than
| once?
|
| I applaud you for your honesty, but... Really?
| jazzyjackson wrote:
| Bro, really, self-taught people with a bare minimum
| understanding of the tools they use are super normal, and
| when they get into a pit they have to fix it themselves.
|
| Although to your point folks would be better served
| carefully reading the docs / git book than googling a
| specific solution to their specific error code.
| antithesis-nl wrote:
| > Bro
|
| Really?
| jazzyjackson wrote:
| I guess we're coming from different places. In my
| vernacular, ending a comment with "...really?" is about
| as casual as calling somebody bro.
|
| It's gender neutral btw.
| leptons wrote:
| "Bro" is the furthest thing from "gender neutral". Not
| sure how you could think it's gender neutral. It
| originated from male behavior and is definitely not
| gender neutral. You can address women as "bro" and they
| might even respond to you but they'll think you're
| absolutely weird.
| jazzyjackson wrote:
| "bro", "bruh", it's more of an exclamation of surprise
| than a title conferred to the person being addressed, but
| even then, I don't know, people call folks "auntie" and
| "uncle" who aren't actually their auntie and uncle.
| language is flexible. it may reference the kind of
| fraternity between brothers but that feeling is not
| limited to the male sex.
| kstrauser wrote:
| Can confirm. It sounds so weird to me, but I hear my kids
| and their friends call each other "bro" or "bruh" all the
| time, regardless of gender.
| DangitBobby wrote:
| No, the female and non-binary people in my life both give
| and accept "bro" or "bruh" without complaint. I once
| asked one of my non-binary friends directly how they felt
| about "bro", "dude", etc and they consider those words to
| be gender neutral. They are like the word "man" now ("IDK
| man").
| Terr_ wrote:
| > They are like the word "man" now ("IDK man").
|
| That's actually how it was originally, because in Old
| English "man" just meant a gender-neutral "person."
|
| Gendered versions were "wer" and "wif", so you could have
| a "wer-man" and a "wif-man", the latter changing
| pronunciation to become "woman". I suppose this also
| means that there are both "werewolves" and "wifwolves".
| spokaneplumb wrote:
| I'm about 95% sure that if I ask my two school-age
| daughters if it's weird to address girls and women as
| "bro" or "bruh" in informal circumstances, they'll say
| no. Since I hear them do it with some regularity.
| syndicatedjelly wrote:
| U r
| kstrauser wrote:
| For me, the value of things like this is in learning the
| terminology for what I broke and how to fix it. I'm not
| going to copy-and-paste advice off the Internet. I never
| have. It's still super helpful to see "oh, that thing I
| want to do is called frobnitzing the corple. Now I know
| what to Google!"
| recursive wrote:
| Yes. I think the ratio of small-team repos this describes
| is close to 100%. You seem to have a certain idea of how
| repos are managed. I don't think it's very representative
| of reality.
| PaulDavisThe1st wrote:
| I've been using git for at least 6 years now, maybe 10.
|
| Sites like this are a great aid to remembering how to deal with
| certain situations. And yes, I understand what the commands do,
| but that doesn't mean I always could, or always want to, put
| together the series of steps from scratch.
|
| And also, we self-host our own gitea hosting because we're not
| getting sucked down by yet another hosting debacle (old enough
| to have suffered under sourceforge, and don't plan on getting
| in the same situation again). For git hosting just as much as
| everything else on line, if you're not paying for it, you're
| not the customer.
| antithesis-nl wrote:
| > For git hosting just as much as everything else on line, if
| you're not paying for it, you're not the customer.
|
| Yeah, lovely trope, but I'm literally talking about
| organizations hosting their Git repos on a file share here.
| PaulDavisThe1st wrote:
| Why would you ask employees of a file hosting service about
| how to use git?
| jpeloquin wrote:
| Recipes like these aren't useless, but yes, they really need to
| be prefixed with whether they expect to start from a clean work
| tree and empty staging area. Or describe what they'll do to
| uncommitted changes, both staged & unstaged. Otherwise they
| pose a substantial risk of making the problem worse.
| conkeisterdoor wrote:
| > "... or worse, your entire 'secret' MP4 collection to our
| monorepo?"
|
| Oh no, that poor soul...
| divbzero wrote:
| Previous discussions:
|
| _Oh Shit, Git_ - https://news.ycombinator.com/item?id=31874308 -
| June 2022 (232 comments)
|
| _Oh Shit Git?_ - https://news.ycombinator.com/item?id=24173238 -
| Aug 2020 (156 comments)
|
| _Oh shit, git (2016)_ -
| 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 - Dec 2017 (509
| comments)
| Rooster61 wrote:
| Unable to access this. Might be hugged to death
| tonymet wrote:
| https://archive.is/qXlY7
| Retr0id wrote:
| my main use case for LLMs these days is asking it how to (un)do
| things with git
| tantalor wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| julianeon wrote:
| I actually use git for my todolist/diary and I have an alias
| for when I want to save which does git commit -m "whatever."
| Basically I do that so I can view the updated version in the
| mobile app.
| tonymet wrote:
| github's "reflog" is the activity log API
| 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 wrote:
| 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 wrote:
| 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.
| globular-toast wrote:
| 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.
| koito17 wrote:
| Agreed that UIs generally provide a better UX for Git.
|
| I use Magit and doing things like "abort cherry-pick" is
| _discoverable_ in the interface itself and uses the exact same
| shortcut as the other "abort X" operations. If I had to use
| the Git CLI, I'd have no idea where to start.
|
| Similarly, I've made mistakes in interactive rebases where I
| deleted a commit that shouldn't have been deleted. If I recall
| correctly, the start of every rebase creates a snapshot that is
| accessible from the reflog, so this is a safe way to revert
| changes from a rebase gone wrong. Magit's UI for the reflog is
| exactly the same as the UI for the log, so I was not lost when
| I saw it for the first time. With the Git CLI, I'd likely have
| no clue what's going on.
| JTyQZSnP3cQGa8B wrote:
| I agree, I have used git for more than 10 years and it's the
| only tool that I refuse to learn. The command-line interface is
| cryptic and infuriating. I'd rather write assembly language
| again than learn what is essentially a CLI to the internals of
| git. It's not high-level, it's not intuitive, and it can be
| destructive if you don't use the right option. I stick to GUIs
| and simple actions, and I never had any problems compared to
| all the horror stories of my CLI-loving coworkers.
| taberiand wrote:
| I advocate this with every newbie to git - find a UI that works
| for you and use it over the cli. Barely anyone listens though,
| and then they struggle with the cli and make a mess of their
| branches and fall out of date with main and are scared of
| rebasing and have many other issues that are solvable with a
| drag and drop or similar in a UI. I figure it's a sort of
| masochism.
| MrJohz wrote:
| I've started recommending jj as a (git compatible) alternative
| to git, and one of the things I like about it is that the
| default action if you run `jj` with no arguments shows the
| relevant parts of the commit tree and where you are in it. This
| is a great reorientation tool, because you can see at a glance
| which commit you're working on right now, the branches and
| history associated with it, any other active branches in your
| repository, and for each you can see whether each commit had
| messages, changes associated with it, etc.
|
| It's really powerful because it gives you precisely that visual
| layout that shows you what's going on in the repository, and
| what you're doing right now.
| marssaxman wrote:
| I have not used such a tool in a long time, and never with git:
| but my past experience with GUI frontends for version control
| was that they work fine when everything is working fine, but
| once you have a mess to clean up, nobody can help you.
|
| It has generally worked better for me to use the same interface
| everyone else is using, even when that interface is awful,
| because that eases communication with the rest of the team. It
| also lets me take advantage of online troubleshooting
| resources, which all assume you are doing things the normal
| way.
| franky47 wrote:
| 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 wrote:
| I have had git corruption problems on a raspberry pi sd card,
| usually I just had to reclone/abandon that folder
| amelius wrote:
| This is why I run Git inside Git, as the latter allows me to undo
| anything I do within the former.
| CharlesW wrote:
| 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 wrote:
| 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 wrote:
| Literally `git reflog`
| javier_e06 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| daitangio wrote:
| I love this site, it helped me and it also funny. Kudos to the
| creator!
| bitwrangler wrote:
| Other fun git hacks...
|
| * https://hackaday.com/2017/05/23/stupid-git-tricks/
|
| * https://ongardie.net/blog/sqlite-in-git/
| grokx wrote:
| I can also recommend git flight rules:
| https://github.com/k88hudson/git-flight-rules
|
| It saved my work a couple of times.
| mfashby wrote:
| Related, you can get this as a nice printed zine
| https://jvns.ca/blog/2018/10/27/new-zine--oh-shit--git-/
| frakt0x90 wrote:
| 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 wrote:
| This should be a built-in git unshit
|
| Or git add --unshit -f ~HEAD^^
|
| If you're using git version <= 2.844.
| spokaneplumb wrote:
| I've been using Git for almost 15 years, and have _twice_ built
| programs /products that use Git internally to achieve certain
| results (that is, the program/product itself uses Git for
| things, not just using Git to manage the source code for the
| program/product) and... sometimes before doing something a
| little gnarly in Git I'll still just do "cp -R .git ../git-
| backup" or something like that, so I can replace my entire .git
| dir with an older copy if I screw it up too bad. It's a ton
| faster than figuring out the right way to un-fuck any
| particular operation or set of operations.
| fragmede wrote:
| Reflog is your friend. git break-my-shit
| git reflog ... output saying where you were
| before things broke ... grab the good commit sha
| git reset --hard good_commit_sha_from_reflog
| philipwhiuk wrote:
| My hot take is that Git isn't nearly as hard as the endless blogs
| pretend.
| reaperducer wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "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.
| jeppester wrote:
| 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.
| tester756 wrote:
| >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.
|
| For example: you have bazilion ways to achieve the same
| thing, all of them having its own quirks/advantages?
|
| It is just poorly designed, that's it, lol.
|
| I like to joke that if somebody else invented Git, then it'd
| be 10% less powerful, but 10 times more user-friendly
| marssaxman wrote:
| > it really isn't that big of a deal if you understand the
| basics of what a commit is, what a branch is etc.
|
| Yes, that's what people mean when they say git is hard.
| Instead of presenting you with an interface expressed in
| terms of the domain you intend to work in, whose commands
| represent the tasks you intend to perform, git just dumps its
| guts all over the place, requiring each git user to re-
| implement the interface between "what you want to do" and
| "how git is built" inside their own brains instead. Once you
| have written git's missing user interface in your brain, you
| are fine; but that's a lot of work which is generally not
| necessary when using other version-control systems.
| ioncannon wrote:
| Hey I worked with the person who made this! She did a fun
| presentation for our company.
| codazoda wrote:
| Is this related to "Oh Shit, git?" by Julia Evans?
|
| 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 wrote:
| Yes! Katie and I made it into a zine because I was such a huge
| fan of her work on https://ohshitgit.com/. (you'll notice she's
| a coauthor of the zine)
| globular-toast wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| svn is perfectly fine and intuitive as long as you never want
| to branch and merge
| grandiego wrote:
| 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 wrote:
| 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.)
| steveklabnik wrote:
| The GitHub effect is real, like all network effects, but that
| doesn't mean improvement is impossible. I've switched entirely
| to jj, and it having git compatibility means that I don't need
| to rely on anyone else to make that happen.
|
| I am growing increasingly frustrated with various aspects of
| GitHub, and so I hope someday we all move past it too, but I
| don't think there's as simple of a path forward there.
| acombandrew wrote:
| this is good but is extremely reddit
| julienb_sea wrote:
| 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...
___________________________________________________________________
(page generated 2025-01-16 23:00 UTC)