I generally agree with this answer and disagree with the downvotes, but I think saying that it will forget the last commit you were on seems a bit odd. The whole reason people run git pull is because they want to update their local files to match the remote. Of course it would change what commit you're on. If you weren't trying to make that happen, why else would you be running git pull?

Also, would git checkout - work to go back to the previous commit after a pull?

I think git-checkout(1) does not have a - argument. There are other probably more specific ways to name the last state of HEAD in git(1), which I never remember because those are things I rarely use (thankfully, I don't break my repos often :).

Regarding the want to match the remote: yes, that's what you want.

In the easiest case, you're fast-forwarding a master branch where you don't work, and only pull the state of a repo. There's nothing that can go wrong there.

But as long as you work in the master branch (e.g., you're a developer of a project), and try to push changes in that branch, at some point you'll find that someone else pushes changes at the same time as you, and you need to fetch and rebase. This is solved by forcing a fast-forward in git-pull(1), so that it will fail and you'll manually rebase.

Another case is where you don't necessarily trust the remote. If you want to check the contents of the remote (e.g., PGP signatures), you'll need to fetch first...

... unless all commits are signed, in which case you can tell git(1) to automatically check signatures on all commits.

So, in some cases, git-pull(1) works. But when something deviates from it, it's better to git-fetch(1) and later do whatever. In general, to prevent those problems before they happen, I choose to always git-fetch(1) instead of pulling.

Thanks!

And even when I want to get the changes blindly (e.g., I'm contributing a patch (which I have on a branch called len) to GCC, and want to rebase my patch on top of the latest GCC master), I want to keep track of what the old state of master was.

That allows me to later run the following command after the rebase:

git range-diff master..alex/len gnu/master..len

This allows me to check what has changed during the rebase, to review if I did any mistakes (this has helped me catch rebase accidents several times).

Once I've finished reviewing the rebases, and only after that, I fast-forward the master branch.

Thanks for the response. I'm pretty sure there is in fact a git checkout -, it works for me, although it might possibly be an alias I got from oh-my-zsh. It works analogous to cd -. However, I checked and although it can switch to the previous branch, it cannot switch to the previous HEAD before pulling. You're right, there are other ways to find out what the last HEAD was.

Btw, generally I agree with your answer. I also have git configged to do only FF and try to fetch rather than pull, since I got burned by it too many times.

In git-checkout(1), I couldn't find documentation for -.

And:

$ git checkout -
error: pathspec '-' did not match any file(s) known to git

I guess it's a weird shell extension. :)

alx‭ That's strange, it should work. Check the release notes for version 1.6.2:

"git checkout -" is a shorthand for "git checkout @{-1}"

And the documentation says that "construct @{-<n>} means the n^th branch/commit checked out before the current one".

I use it a lot, BTW. I've made a test here, with a new repo and I've got this "pathspect '-' did not match..." error only when there were no previous checked out branches. But as soon as I created another branch and switched to it, git checkout - worked and got me back to the previous branch.

And the same documentation describes a way to know where HEAD previously was.

Basically, HEAD@{n} (with n being some number) specifies the n-th prior value of HEAD (and you can change HEAD by any other ref, BTW - it can be a branch name, a commit, and so on).

And you can also do things like git log "HEAD@{5 minutes ago}", or git log "HEAD@{2024-08-20 08:20:00}", or git log "HEAD@{yesterday}", etc, to find out where HEAD was at a particular point in time. Or use some special refs such as FETCH_HEAD (the branch which you fetched from a remote repository with your last git fetch invocation), ORIG_HEAD (where HEAD was before some operations such as merge, rebase, etc) and others mentioned in the same link.

I agree that the best approach is to avoid getting into a situation where you need to use those things. But if you do, Git provides you many ways to solve it.

hkotsubo‭ That's neat! Worth posting as an answer to https://software.codidact.com/posts/292312 IMO