Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on Is `git pull` dangerous?

Parent

Is `git pull` dangerous?

−2

I heard git pull is dangerous.

Is it really dangerous?
If so, why or how is it dangerous?
Are there any flags that mitigate or remove the danger?
What are the alternatives if it is dangerous?

git

posted 2 months ago

CC BY-SA 4.0

2mo ago by Andreas lost his angel wings‭

alx‭

569 reputation 16 9 87 125

Raw

Markdown

History

is a duplicate

This question has been asked before and has already been answered. It should be marked as a duplicate.

Please enter the URL of the proposed duplicate in the details field below.

not constructive

This question cannot be answered in a way that is helpful to anyone. It's not possible to learn something from possible answers, except for the solution for the specific problem of the asker.

1 comment thread

Unclear (3 comments)

Post

−3

git pull is dangerous, but not a security problem. The only danger is that it's difficult or inconvenient (but not impossible) to recover to the state prior to the pull, if it would be necessary.

Merge commits

The remote branch might have diverged from your own, in which case git will automatically try to resolve any conflicts with a merge commit. This might result in bad conflict resolutions (although that's rare).

This can be solved by running git pull --ff-only instead, which will only merge the origin changes if your local branch can be fast-forwarded (no merge commits).

If there are any local changes not in the remote branch, the pull will fail, and you'll be able to resolve the situation with a different method.

However, this solution doesn't solve the other problems of git-pull(1), so continue reading.

Predictability

git-pull(1) performs two operations:

download the latest branch from the remote
merge it to the local branch

But you can't predict what's in the remote branch. This means that your local branch will blindly jump to whatever commit the remote branch is in (assuming git pull --ff-only, and that your local branch has no changes).

You won't know where your branch was prior to the jump, unless you wrote the old commit hash somewhere. If after the pull you find out that you don't like the changes and want to go back to the old state, it will be hard to know where you were. (Imagine for example that the remote could have been hacked, and malicious contents could have been introduced in the branch.)

git-pull(1) has no way to mitigate this, since it's a problem inherent to the fact that git-pull(1) performs two operations.

The solution is to run two commands to perform those operations separately:

git fetch origin
git merge --ff-only origin/master

Between the fetch and the merge, you can print a graph of the log, to analyze what will be merged:

$ git fetch origin
$ git log --all --graph --oneline
$ git merge --ff-only origin/master  # or rebase, or whatever you need; you already know what you're merging.  :)

Printing the log graph in the terminal will also let you have all the commit hashes written, in case you make any mistakes and need to go back to the original state (git reset <old-master> --hard) and start again.

This approach allows you to review all of the remote commits before merging them into any local branch.

posted 2 months ago

CC BY-SA 4.0

2mo ago

alx‭

569 reputation 16 9 87 125

Copy Link

Raw

Markdown

History

3 comment threads

Losing old HEAD is not unpredictable (9 comments)

Unfamiliar notation (7 comments)

Use config rather than command-line flags (4 comments)

matthewsnyder‭ wrote about 2 months ago

copy link

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?

alx‭ wrote about 2 months ago · edited about 2 months ago

copy link

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...

alx‭ wrote about 2 months ago · edited about 2 months ago

copy link

... 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!

alx‭ wrote about 2 months ago · edited about 2 months ago

copy link

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.

matthewsnyder‭ wrote about 2 months ago

copy link

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.

alx‭ wrote about 2 months ago

copy link

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. :)

hkotsubo‭ wrote about 2 months ago · edited about 2 months ago

copy link

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.

hkotsubo‭ wrote about 2 months ago · edited about 2 months ago

copy link

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.

Communities

Comments on Is `git pull` dangerous?

Is `git pull` dangerous?

1 comment thread

Merge commits

Predictability

3 comment threads