The easiest way would be to find the head commit of the branch as it was immediately before the rebase started in the reflog...
git reflog
and to reset the current branch to it (with the usual caveats about being absolutely sure before reseting with the --hard option).
Suppose the old commit was HEAD@{2} in the ref log:
git reset --hard HEAD@{2}
In Windows, you may need to quote the reference:
git reset --hard "HEAD@{2}"
You can check the history of the candidate old head by just doing a git log HEAD@{2} (Windows: git log "HEAD@{2}").
If you've not disabled per branch reflogs you should be able to simply do git reflog branchname@{1} as a rebase detaches the branch head before reattaching to the final head. I would double check this, though as I haven't verified this recently.
Per default, all reflogs are activated for non-bare repositories:
[core]
logAllRefUpdates = true
Run this from the branch where you want the file to end up:
git checkout otherbranch myfile.txt
General formulas:
git checkout <commit_hash> <relative_path_to_file_or_dir>
git checkout <remote_name>/<branch_name> <file_or_dir>
Some notes (from comments):
- Using the commit hash, you can pull files from any commit
- This works for files and directories
- Overwrites the file
myfile.txt and mydir
- Wildcards don't work, but relative paths do
- Multiple paths can be specified
An alternative:
git show commit_id:path/to/file > path/to/file
Best Answer
Use
to apply
<commit>to your current branch.I myself would probably cross-check the commits I pick in
gitkand cherry-pick them with right-clicks on the commit entry there instead.If you want to go more automatic (with all its dangers) and assuming all commits since yesterday happened on wss you could generate the list of commits using
git log(with--prettysuggested by Jefromi)so everything together assuming you use
bashIf something goes wrong here (there is a lot of potential) you are in trouble since this works on the live checkout, so either do manual cherry-picks or use rebase like suggested by Jefromi.