ksylor / ohshitgit Goto Github PK

The instruction block from the website is screenshoted below.

I just ran into such situation right now. While the approach itself is good, this can completely delete newly created files and there would be almost no options to restore them.
I think you should consider deleting this block from the site in favor of always doing git reset HEAD~ --soft because it's more safe. I think plenty of people have lost their changes thanks to you. Don't advise people to do so, this is harmful advise. Or you should at least mention this in red and CAPS ON.

Should be always superseded with (because it's more safe):

I think Dark mode will be a very good addition to this site, So I added it as It was mentioned in contributing guidelines to open an issue for discussion I am opening this issue.

Current Dark mode Implementation Screenshot

Any feedback Regarding color choice will be appreciated.

The code is too light to be read properly. Furthermore, it is completely white when I highlight it.

I want a previous version file from a given commit ID:

git show <comment-id>:<filename> > <newname> 

# example
git show 7926ba:README.md > READYOU.md

Proposing an addition along the lines of...

Oh shit! I ran git pull in the wrong branch and now my PR has a merge commit, and it disappears on rebase, but also I ammended the merge commit with more changes and those disappear as well!

Presumably with the proposed solution of (unless someone has a better way):

# remove all the commits from your branch, without removing the changes
git reset master
# manually pick the changes that do belong in your PR (any commits added to master since the last branch rebase will appear undone after the reset)
git add -Ap
# recreate the commit(s) without any merges; push
git commit ...; git push -f ...
# clean up the rest of the changes
git reset --hard

Proceed to $ingest heavily.

( Possibly prefixed by git reflog; git reset --hard $MERGE_COMMIT when trying to fix this after finishing a rebase. )

Since git 2.23, there have been two other commands added in replacement of git checkout.

git restore can be used to revert the changes of a file at a given commit.

git switch to switch to a branch after creating it if necessary.

These two new commands can be very helpful to understand better what is actually being done, and git restore is probably easier to remember than git checkout <hash> -- <file>.

Hello, I've used that command a lot for various situations, when git behaves really strange. Maybe it would be worth it adding?

This is a toggle, so it won't allow you to page back through an arbitrary number of locations on the tree, but it is suuuuuper useful for when you've to flip to someplace really quick and then back to where you came from.

your-branch  $ git checkout their-branch
their-branch $ git log -p # or whatever y'all're on this branch to do
their-branch $ git checkout -
your-branch  $ git checkout - 

And it works with SHAs, too!

your-branch $ git checkout s0mesha
s0mesha[…]  $ git checkout -
your-branch $ git checkout -
s0mesha[…]  $

https://ohshitgit.com/#fuck-this-noise

In the tutorial to reset the whole repository, the command git clean -df can use the -x flag too, to remove untracked files that might have been messing things up for the reader (although they can totally come back after some time).

It might also be a good idea to mention that the .git directory might contain custom ignores, hooks among other wacky magiks that will be lost on reset, although I reasonably suspect that the average reader of this site wouldn't have touched it.

Thoughts?

git reset --soft HEAD~1

Never do this on a public commit

Auto deploy preview give error 404 on new push.

Currently, there's only one ASCII emoji in the repo (¯_(ツ)_/¯ in the dude-wheres-my-diff file), but it would be nice to have in accessible form users who use screen readers, as it is recommended to do for ASCII art and emojis.

I'm opening the discussion about as an issue, as is stated in the CONTRIBUTING.md file about content changes.

One way to do this could be, for example (this is something that I found on the internet, haven't tested it fully, but will if I can submit a PR to this issue):

File under <span aria-hidden="true">&macr;\\\_(ツ)\_/&macr;</span><span class="sr-only">shrug</span>

and then add the sr-only class to site.css:

.sr-only {
      position: absolute;
      width: 1px;
      height: 1px;
      padding: 0;
      margin: -1px;
      overflow: hidden;
      clip: rect(0, 0, 0, 0);
      white-space: nowrap; /* added line */
      border: 0;
}

(Example CSS code from a11y guidelines

Let's be fair: nobody uses revert for fun, and reset is a landmine if used incorrectly. You don't need them anyway, since we have:

git checkout *hash* .

Which resets all files to the status of that commit. Combine with git clean -df to remove any file or directory that wasn't being tracked at the time. Run a new git commit and boom, back to work. Nothing (of value) was lost.

And when I do git rebase main it just tells me that everything is already up-to-date 😱.

$ git rebase --onto <new-start-point> <old-start-point> <branch-to-change>

RTFD 😮‍💨 Thanks git.

First: Huge fan, Thank you thank you. Have visited site 1,000+ times and has been hugely helpful in workflow. OhShitGit has saved me hours/days/weeks of time at this point ! And I get lots of questions/compliments on the stickers :-).

git commit --amend --no-edit
and
git reset HEAD~ --soft
git stash
truly are superpowers.

One new command I have learned recently is

git commit --allow-empty
git commit --allow-empty -m "kick the build"

Would like to suggest this addition as has become another command that I am using frequently and I feel that not many people know of this functionality.

If we want to include / add this to the repo, I can take on the translations as well, and will tap my friends and network and work with the community here to ensure the translations are grammatically correct.

Thank you again !

The directory is owned by regular user, just use rm -rf the_git_directory, sudo is not needed.

For the example about accidentally committing to master instead of a branch, instead of using HEAD~, I think the example should use origin/master. This will remove the need for the note that explains how to remove multiple commits to master, though I suppose it's still worth noting that origin/master might be different if your master branch is named main or something.

Sometimes we tend to make multiple commits related to the same thing and it's better to have one final commit that contains all the changes related to that commit. We can squash multiple commits into one using the concept of rebasing and squashing the commits we want to be merged into one.

git rebase -i HEAD~2 <-- 2 being the number of commits that you want to rebase.
[ pick older-commit ] <-- You need to have one commit that is going to serve as the commit that all the squash commits are going to go into.

[ squash newest-commit ] <-- All the commits with the message squash will be merge into the commit that has been marked as pick

Example:

git rebase -i HEAD~2 
    [ pick     older-commit  ] 
    [ squash   newest-commit ]
git push --force

There are two kinds of people:
the ones that pushed cringe and the ones that use this

git reset --soft HEAD~1
git push --force

use with caution and with the supervision of an adult.

Variant: A coworker pushed some changes to some branch but didn't tell me where.

Possible solution:

git log --all --graph --decorate

Do you think this can be a useful addition to the list?

Hi @ksylor,
currently https://ohshitgit.com/gr is unavailable, can you check and restore it?

Thank you

One of my favorite git tricks, this allows you to amend an old commit when you realize there's small changes needed, like fixing a typo or a small bug.

Note that this should only be done on a branch, or for commits which you haven't yet pushed, as this is re-writing history. Thus, if you've already pushed the commit you're editing, you'll need to force-push them the second time.

Steps are:

• Make the changes
• Stage the changes
• Find the sha of the commit you want to add the staged changes to (referred to as [sha])
• git commit --fixup [sha] – this creates a 'fixup' commit.
• Optional: if you have other unstaged changes, you'll need to stash or commit them before the next step.
• git rebase -i --autosquash ^[sha] – the upwards-caret indicates you want to rebase up to the commit before the original commit you're fixing up.

Note that if you're fixing up multiple commits simultaneously, the final 'autosquash' rebase will need to be of the oldest commit being fixed up.

Also note that this can potentially cause merge conflicts if the changes aren't small and conflict with other intervening changes. So use sparingly.

Good article here: https://thoughtbot.com/blog/autosquashing-git-commits

Hello

It is a real pity and a shame that this great tutorial uses such repulsive terms.
They're neither cool nor useful - but they're messing up the great work.

Your work would have been worth far more than 6 watcher - but maybe it's just for personal use anyway.

Kind regards,
Thomas

Please add link to https://ohshitgit.com as google is the only way to understand what it is.

I put together a VS Code extension that uses the hosted content from this repo. As often, when you f-up with git, you're already in an IDE anyway.

The code base for this extension doesn't really belong in this repo, but happy to share code/open source with permission to use the content. It currently supports:

• VS Code themes
• Multi-Languages

This is it in action:
https://user-images.githubusercontent.com/1678318/105904707-64693f00-6019-11eb-9d2a-e99ca9f435fa.mp4

Also added some handy Command Palette lookups for the various sections:

In the first tip, may I suggest

git reflog --date=relative

Because then you can see when you went wrong. :-)

it is listed in your redirects but throws HTTP 500 -- https://ohshitgit.com/en

This is the process for cleaning up a repo after you've accidentally added files you meant to ignore - like __pycache__ or .idea files from your IDE. (I can't be the only one who does this regularly, right?)

Maybe worth discussing is whether there's a better way to do this that doesn't require running rm -r. You don't lose data or files or anything with the --cached flag, but it's still nerve-wracking the first time you have to do it.

# make sure everything is committed
git commit -a
# update your .gitignore 
# check git status to find the files/directories you need to add
vi .gitignore
# remove everything from source control
# do NOT forget the --cached flag
# you can do --dry-run first to test things out
git rm -r --cached .
# re-add everything to git, then commit
git add .
git commit -m ".gitignore fix"
# push if you also messed up remote
git push origin BRANCH

I put up a draft PR on my fork if that's helpful.

Hi
This repository is really hooked me,
and I'd like to add a new translation for Arabic language,
If this could happen please assign this task for me and I'll start.
Thanks

This happened to me, and I did eventually deal with it.

I came across Git How-to: Remove your password from a repository by David Verhasselt.

I recommend you contact David and ask him if you can use it. Or I can contact him and ask on your behalf, as you prefer.

/Jeff

In my experience, the most common "getting stuck" situation for novice git users is getting stuck doing a rebase or a merge with conflicts.

In these situations, doing git merge --abort or git rebase --abort will put you right back where you were before executing the merge or rebase, and is the simplest way to recover from accidental bad merges or rebases.

I think the page should probably mention these commands because they very simple and work in the most common situations.

It would be nice to have a search engine to search for a problem in the contents 😍

This is my biggest headache, just like this one and there is no easy solution for it.

Compare to this one all the other problems are just easy-peasy.

There are a lot of issues which have no answers and a lot of PRs. Is the repo / website still maintained? Is there a successor?

Where do i contact or suggest more oshits?
How about explaining the ever confusing terms of checkout and checkin used by the git community
pulls hair

regarding this https://ohshitgit.com/#fuck-this-noise

you can add -v to command because when you realize you fucked up, you at least know what you deleted

sudo rm -v -r fucking-git-repo-dir

it's an easy SEO win, and I'd love for more people to know about this site, cause it rocks.

I'm happy to raise the PR if that would be helpful.

Keep up the great work!!!

for reference, here's the current SEO score on the lighthouse audit:

(PS - I would love to submit a PR to increase the tap targets as well if that would be helpful)

I'll post a PR for this a bit later, but there should be an entry for renaming "master" to "main" (or whatever). Also, the page itself should use "main" in place of "master".

• Why GitHub renamed its master branch to main

A lot of new developers find themselves in their first job, using git on the command line, and realizing that, when they commit, it opens a vi session for them to enter a commit message. This leads to the trope of "How do I exit the Vim editor?" being one of the most highly read entries on Stack Overflow. A sister site containing similar trouble spots for vi would be amazing.

As requested, creating issue rather than submitting pull request.

Title says it all - these days no-one should ever be using --hard unless they are completely intentionally unrecoverably destroying uncommitted data. We should use merge instead, which is the same thing EXCEPT it will fail to destroy your work.

Proposed change fwiw: TaoK@c6fab3e

IMHO, new font rendering too bad on russian language in italic and mono versions.
My opinion about font pairings:

• Montserrat (titles)
• Roboto (main)
• Jetbrains Mono (code)

Really nifty command to switch to a different branch with current changes. Equivalent of stash -> checkout -> pop