Hmm, I agree. Dangerous was too strong of a word; I've lessened that to clarify that it's not a security concern, but just an inconvenience.

However, I don't agree that git-reflog(1) solves the inconvenience. It is part of the inconvenience. It just makes it not a total disaster. But a git-log(1) before merging is (IMHO) better than a reflog afterwards.

Sure. If you have some reason to think the next merge/rebase may cause issues, getting the hash ahead of time may be a bit more convenient. That said, a git fetch won't change the git log output, so you could just as well git log before the git pull. If you meant to actually look at the log of commits for the fetched changes, then, sure, that's what git fetch is for.

That said, in my experience a git pull is almost always to sync some branch to its latest state. The actual merge that might be problematic is when I want to merge changes into my branch which wouldn't be a pull anyway. Generally, the only time a git pull has been "risky" for me is in the rare cases when I was working independently to someone else on the same branch.

Most of the time it doesn't, but when it does it's already late. :)

And yes a git-log(1) before the pull/fetch should be enough for being able to revert, but then it's harder to see the diff, that is, see what's only on the remote.

Even if you trust the author of the remote, you may not trust the remote (it might be hacked). To be cautious, I'd at list like to see at first glance a one-liner list of changes that I'm pulling, so I can see if those are properly signed. My full list of git aliases is:

[alias]
	lgo = log --graph --oneline --abbrev=12
	lago = lgo --all
	lg = log --graph --abbrev=12 --decorate \
		--format=format:'%C(bold blue)%h%C(reset) %C(magenta)%G?%C(reset) - %C(bold cyan)%ai%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''  %C(white)%s%C(reset) %C(dim white)- %an%C(reset)'
	tree = lg --all
	ff = merge --ff-only

With git tree, which is what I use after a fetch, I print with %G? a small status of the signature of each commit. ...

git-log(1):

             %G?
                 show "G" for a good (valid) signature, "B" for a bad
                 signature, "U" for a good signature with unknown validity, "X"
                 for a good signature that has expired, "Y" for a good
                 signature made by an expired key, "R" for a good signature
                 made by a revoked key, "E" if the signature cannot be checked
                 (e.g. missing key) and "N" for no signature

So I can see there are 10 new commits in the remote, and that they are signed. Even for my own server, that makes me confident that I'm pulling my own commits, and not some malicious changes.

This is more compelling, but it is also what git merge/pull --verify-signatures is for. If you expect all commits to be signed you can set the config merge.verifySignatures to true to have this happen automatically. In the case where you expect a mix of signed and unsigned commits, then you can run git pull --verify-signatures. If succeeds, it will proceed with the merge without you needing to painstaking check for a bunch of "G"s. If it fails, then it will tell you which commits failed and you can check those specifically and then git merge without --verify-signatures once you've checked them all (assuming they look good). This lessens the chance that you simply fail to notice an unverified commit, or you don't check because you're in a hurry. Even better if you set merge.verifySignatures and only disable it via --no-verify-signatures when you need to.

And it's only "too late" to check after merge in the sense that it's inconvenient, though it is better to check before.

I wish I could do that, but I have to work with other authors who don't sign their commits. :|

But yeah, that's something quite useful for my own projects. Thanks!