cherry-pick a commit and keep original SHA code

Question

I would like to cherry-pick a commit on a fetched remote while keeping it\'s original SHA commit code (my current branch is based on this remote which I resetted to a previous s

Answer 1

Go into interactive rebase ("git rebase -i") and paste a new entry at the end with the exact revision you want to prepend to your HEAD.

Example:

Open an interactive rebase session:

$ git rebase -i HEAD~4

The screen now shows [something like] this:

pick efdd0ece Linked how to make a pull requests in README
pick 790a3be8 adjust pytest pins to fix testing infra
pick 5bb90d8f drop 3.4 support
pick 839dc8ba v2.22.0
pick b97fb61a Print the type of the password instead of the password itself

Your current HEAD is the last entry. Add a new entry to the bottom (just "pick" and your revision; no description necessary) with the exact revision that you want to prepend:

pick efdd0ece Linked how to make a pull requests in README
pick 790a3be8 adjust pytest pins to fix testing infra
pick 5bb90d8f drop 3.4 support
pick 839dc8ba v2.22.0
pick b97fb61a Print the type of the password instead of the password itself
pick 2a173c2a6491aae0772640ba7946a08315d18eb8

Save and close. That exact revision will now be your HEAD:

$ git log --oneline | head -n 6
2a173c2a Some commit
b97fb61a Print the type of the password instead of the password itself
839dc8ba v2.22.0
5bb90d8f drop 3.4 support
790a3be8 adjust pytest pins to fix testing infra
efdd0ece Linked how to make a pull requests in README

As mentioned in other answers, you still have to follow the rules. This works in only the very narrow case where you have the exact same branch, parents, and committer (such as with a code-review-centric process where you have a bunch of commits queued up somewhere, where the developers can push them up and bring them down without necessarily submitting them into the repository first); really only when the timestamps are the only thing that might have changed. In this case, you can force the identical revision in order to force the timestamps to be unchanged.

In most other cases, the parent will usually be different, and, this alone, means that your dream of forcing a certain revision will be dead. Git will always fix-up the revision to be correct if any of the non-timestamp factors are different.