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.
Post History
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. ...
Answer
#7: Post edited
by
alx
·
2024-08-18T14:44:11Z (2 months ago)
`git pull` is dangerous, but not a security problem. The only danger is that it's difficult (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:
- ```sh
- $ 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.
- `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:
- ```sh
- $ 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.
#6: Post edited
by
alx
·
2024-08-18T14:18:01Z (2 months ago)
`git pull` is dangerous.- ---
- ### 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:
- ```sh
- $ 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.
- `git pull` is dangerous, but not a security problem. The only danger is that it's difficult (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:
- ```sh
- $ 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.
#5: Post edited
by
alx
·
2024-08-18T09:49:23Z (2 months ago)
- `git pull` is dangerous.
- ---
- ### 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:
- ```sh
- $ git fetch origin
- $ git log --all --graph --oneline
$ git merge --ff-only origin/master # or rebase, or whatever you need; it's a local change, anyway. :)- ```
- 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.
- `git pull` is dangerous.
- ---
- ### 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:
- ```sh
- $ 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.
#4: Post edited
by
alx
·
2024-08-18T09:48:17Z (2 months ago)
- `git pull` is dangerous.
- ---
- ### 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:
- ```sh
- $ git fetch origin
- $ git log --all --graph --oneline
$ git merge --ff-only origin/master$ # or rebase, or whatever you need; it's a local change, anyway. :)- ```
- 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.
- `git pull` is dangerous.
- ---
- ### 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:
- ```sh
- $ git fetch origin
- $ git log --all --graph --oneline
- $ git merge --ff-only origin/master # or rebase, or whatever you need; it's a local change, anyway. :)
- ```
- 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.
#3: Post edited
by
alx
·
2024-08-18T09:48:02Z (2 months ago)
- `git pull` is dangerous.
- ---
- ### 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:
- ```sh
- $ git fetch origin
- $ git log --all --graph --oneline
- $ git merge --ff-only origin/master
- ```
- 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.
- `git pull` is dangerous.
- ---
- ### 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:
- ```sh
- $ git fetch origin
- $ git log --all --graph --oneline
- $ git merge --ff-only origin/master
- $ # or rebase, or whatever you need; it's a local change, anyway. :)
- ```
- 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.
#2: Post edited
by
alx
·
2024-08-18T09:41:54Z (2 months ago)
- `git pull` is dangerous.
- ---
- ### 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:
- ```sh
- $ git fetch origin
$ git log --graph --all --oneline- $ git merge --ff-only origin/master
- ```
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.
- `git pull` is dangerous.
- ---
- ### 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:
- ```sh
- $ git fetch origin
- $ git log --all --graph --oneline
- $ git merge --ff-only origin/master
- ```
- 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.
#1: Initial revision
by
alx
·
2024-08-18T09:40:11Z (2 months ago)
`git pull` is dangerous. --- ### 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: ```sh $ git fetch origin $ git log --graph --all --oneline $ git merge --ff-only origin/master ``` 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.