CODEWITHSUNDEEP
gitgit-pushgit-revert
Bashir
Bashir

Reputation: 2051

revert to a commit that does not belong to any branch

I accidently force pushed my repo, so I lost some of my commits which become not belonging to any branch

enter image description here

I tried :

git revert --no-commit <commit>..HEAD

or even

git reset <commit> --hard

but it doesn't work:

fatal: bad revision

is there a way to revert this commit ?

Upvotes: 1

Views: 1632

Answers (1)

torek
torek

Reputation: 489718

This command:

git reset <commit>--hard

is the closest one to correct, but it contains at least one mistake: the --hard is physically joined up against the commit hash, so that the hash looks like a1234567--hard, which is not a valid hash ID.

You might have actually run:

git reset --hard <commit>

or:

git reset <commit> --hard

(which puts the option, --hard, on the "wrong side" of the non-option argument, but Git tolerates this1). If that still did not and does not work—with Git still complaining that it does not recognize the hash ID as a valid commit (fatal: bad revision)—that would indicate that your Git repository lacks this commit. That would be unsurprising because the image you included says:

⚠️ This commit does not belong to any branch on this repository, and may belong to a fork outside the repository.

This particular message is peculiar to those hosting systems that provide "forks" (GitHub and Bitbucket included): the slightly (or heavily) hacked Git implementations on these web hosting sites sneakily share storage across multiple forks, so that it's sometimes possible to gain direct access to a commit that's not in your fork.2 In this case, cloning your own fork might not give you access to that object (see footnote 2 again). One of Git's new features, though,3 means that you can access any object by its hash ID once you know it, so you could just git fetch the object directly, by its hahs ID.

1Git follows a mix of POSIX and GNU option ideas, with its own twists. Many command-line commands on Unix-like systems follow a stricter POSIX-only model, where dash-prefixed options—whether short ones like -x or long ones like --extended—must come before any additional optional arguments such as file names. It's a good habit in general to write things like this, so that when you are using, say, the sed command, you don't get tripped up by option order.

2This has obvious security implications, and if the web hosting site is doing security properly, they won't give you access to any commit that you didn't at least temporarily have access to, long enough for you to have copied the commit. They probably should not give you access to the commit if it such access was "revoked", but supporting revocation correctly is hard enough that they might well just not bother, using the excuse that you had access to it, and you might have copied at during that time, so now there's no point closing the barn door since the horse was (maybe) cloned. Low-to-no-cost copying economies are, obviously, fundamentally different from scarcity economies in which if you have item X, nobody else can have it, and the rules here are still evolving.

3This is the new partial clone feature.

Upvotes: 1

Related Questions