Reset to default
Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.
It falls back to sorting by highest score if no posts are trending.
Throwing away your local changes
If you want to discard your work,
reset. For example, if you have a remote named
origin and a branch named
$ git fetch origin $ git reset --hard origin/master # Destroys your work
Keeping your local changes
If you don’t want to throw away your work, you will have to do a
git rebase --onto. Suppose the old
origin looks like this:
A ---> B ---> C ^ origin/master
And you have this:
A ---> B ---> C ---> X ---> Y ---> Z ^ ^ | master origin/master
Now, the upstream changes change things:
A ---> B ---> C ---> X ---> Y ---> Z \ ^ ---> B'---> C' master ^ origin/master
You would have to run
git rebase --onto origin/master <C> master, where
<C> is the SHA-1 of the old
origin/master branch before upstream changes. This gives you this:
A ---> B ---> C ---> X ---> Y ---> Z \ ---> B'---> C'---> X'---> Y'---> Z' ^ ^ | master origin/master
Notice how B, C, X, Y, and Z are now “unreachable”. They will eventually be removed from your repository by Git. In the meantime (90 days), Git will keep a copy in the reflog in case it turns out you made a mistake.
git reset or
git rebase wrong and accidentally lose some local changes, you can find the changes in the reflog.
In the comments, a user is suggesting
git reflog expire with
--expire=now but DO NOT RUN THIS COMMAND because this will DESTROY your safety net. The whole purpose of having a reflog is so that Git will sometimes save your neck when you run the wrong command.
Basically, what this command will do is immediately destroy the B, C, X, Y, and Z commits in the examples above so you can’t get them back. There’s no real benefit to running this command, except it might save a little bit of disk space, but Git will already purge the data after 90 days so this benefit is short-lived.
I came across a slightly modified version of this scenario. Here’s what I did:
A--->B--->C--->D--->E | local-1/master A--->B--->C--->D--->E | origin/master A--->B--->C--->D--->E | local-2/master
Squash and force push
A--->B--->CDE | local-1/master A--->B--->CDE | origin/master A--->B--->C--->D--->E | local-2/master
Sync changes on local-2/master
$ git reset --soft B A--->B---> (local uncommitted changes) | local-2/master $ git stash save "backup" A--->B | local-2/master $ git pull origin master A--->B--->CDE | local-2/master
If you have not made any changes to the local branch, you could try the following sequence of commands. Please remember this is a crude way to achieve what you are asking for.
git checkout master git pull git remote update origin -p git branch -D myBranch git checkout myBranch
git remote update origin -p is optional.
If you made a changes and you do not care about the contents of the local branch, you could try this:
git stash git stash drop git checkout master git pull git remote update origin -p git branch -D myBranch git checkout myBranch
Both the techniques are really long and cumbersome. But get the job done.
if have NO local commits, this will recover your checkout from a force push. You will be up to date with the remote branch, and can commit your local work later.
git fetch git stash git reset --hard origin/master # destroys your work git stash pop # restores your work as local changes git mergetool # fix any conflicts
At this point you have your local changes as they were before. Your checkout is up to date with all the changes on master, or whatever branch you are working from.