wow, uh. my computer shut off in the middle of a git rebase and now my git repo is corrupted. uhhhhh. that's.
... not good
Mostly harmless
- they
- pkmncards.com/
avatar/pfp: Alixesque
banner: Mermaid Elizabeth
• high school dropout (proud)
• professional computer toucher (remorseful)
• my organic brain was replaced with a NEC V810 when i was 8
• love and kindness 'til we die, baby
gif: @westfailia
You must log in to comment.
in reply to @nago-'s post:
As far as I know, this should still be recoverable, but it may involve somewhat arcane stuff with the reflog...
yeah. it's tomorrow problem tier right now. I use stacked git and I was halfway through a series of 50 patched when it died, so I have to go figure out ... where stacked git keeps stuff now. it's in git somewhere, but there's some surgery to do to figure out where in space and time I even am
First time learning about stacked git and wow that is funky. I am curious how it works under the hood! It sounds like a "patch" is basically a commit still, so is reordering them essentially a rebase...? But then how is "pop" handled?
It feels like I could accomplish everything it does with interactive rebases, but it does seem like a more....convenient way to do that.
It's something I use a lot because some open source projects require pristine but un-squashed commit histories, i.e. it's common for me to be carrying 25-50 patches that will not be squashed when merged; each commit with a detailed explanation of changes in the commit message.
So when I get feedback on patches, it's often convenient to "pop" off some number of patches, modify the commit in the middle, then push the rest back.
You can do it with git rebase -i, but it's slightly more annoying and often more convenient to just pop the patches off.
As a hint: this is an extremely useful tool when using email-based git patch workflow...
Yeah, I was gonna say, this stack-of-patches approach seems ideal for kernel work 😅
that's where it originated from and that's the target audience, yep! I don't work on the kernel, but the project I do work on uses LKML workflow. (Yes, here in 2024)
and apparently, stgit has some kind of weird alternate tree and commit history where it has a repo with a stack.json file and a patches/ folder with patch files in it.
To repair my tree I had to find the latest non-corrupt stgit metadata commit (which I found by using find and timestamps and guess-and-check ...) and fix .git/refs/stacks/my-branch-name to point to that sha; then I had to change .git/refs/heads/my-branch-name to point to the matching "real deal" commit that was at the top of the applied stack at the time.
... and that appears to have done the trick!
I now know way more about how git works than I ever actually wanted to know.