5 ms·

`--force-with-lease` would fix this problem (it needs an alias). Also, `--force` wouldn't cause a merge commit; it would overwrite the remote changes. The only

by Zarel 5y ago

`--force-with-lease` would fix this problem (it needs an alias). Also, `--force` wouldn't cause a merge commit; it would overwrite the remote changes. The only theory that makes sense is that this person doesn't know how to `pull --rebase`, but the order of `push` vs `pull` wouldn't change the presence of merge commits, so I'm still confused.

MereInterest 5y ago
Ooh, --force-with-lease looks like a nice feature, especially for updating github PRs that aren't yet merged. I still wouldn't want to use it where anybody else has a copy of the changes, since that's where you need a merge commit to avoid breaking somebody else's repo, but that gives me a safer option than a blind --force.
- urxvtcd 5y ago
  Just remember that --force-with-lease only protects you from overriding commits you have not yet fetched.
jtbayly 5y ago
I don’t know git well, but I often run into the problem being discussed. If I pull from origin before making my changes, I don’t have to merge, obviously. But correct me if I’m wrong: I think that if I don’t pull first, but my changes don’t conflict with any part of what was done by the previous commit(s) I missed, I’ll still have to merge if I touched a file they touched. This is a common scenario for me. Correct some typos in comments for example, and I get forced to figure out how to merge using vim, which I don’t know how to use at all (being a nano user). I’m sure I could and should switch to at least using nano by default, but I don’t know how merging really works, either. What I really want to do is undo my commit, pull, and redo my commit. Then I don’t have to figure out git merge.
- Zarel 5y ago
  > I don’t know git well, but I often run into the problem being discussed. I do understand the problem being discussed; what I don't understand is what it has to do with pushing first. You have the same problem no matter which order you use `git push` vs `git pull`. > I think that if I don’t pull first, but my changes don’t conflict with any part of what was done by the previous commit(s) I missed, I’ll still have to merge if I touched a file they touched. Yes, that's true. > What I really want to do is undo my commit, pull, and redo my commit. Then I don’t have to figure out git merge. You can do that with `git pull --rebase`, which, as others have mentioned, you can set as the default behavior of `git pull` like this: https://news.ycombinator.com/item?id=27581416 https://news.ycombinator.com/item?id=27581416

by Zarel 5y ago

MereInterest 5y ago

Ooh, --force-with-lease looks like a nice feature, especially for updating github PRs that aren't yet merged. I still wouldn't want to use it where anybody else has a copy of the changes, since that's where you need a merge commit to avoid breaking somebody else's repo, but that gives me a safer option than a blind --force.

urxvtcd 5y ago
Just remember that --force-with-lease only protects you from overriding commits you have not yet fetched.

jtbayly 5y ago

I don’t know git well, but I often run into the problem being discussed. If I pull from origin before making my changes, I don’t have to merge, obviously. But correct me if I’m wrong: I think that if I don’t pull first, but my changes don’t conflict with any part of what was done by the previous commit(s) I missed, I’ll still have to merge if I touched a file they touched. This is a common scenario for me. Correct some typos in comments for example, and I get forced to figure out how to merge using vim, which I don’t know how to use at all (being a nano user). I’m sure I could and should switch to at least using nano by default, but I don’t know how merging really works, either. What I really want to do is undo my commit, pull, and redo my commit. Then I don’t have to figure out git merge.

Zarel 5y ago
> I don’t know git well, but I often run into the problem being discussed. I do understand the problem being discussed; what I don't understand is what it has to do with pushing first. You have the same problem no matter which order you use `git push` vs `git pull`. > I think that if I don’t pull first, but my changes don’t conflict with any part of what was done by the previous commit(s) I missed, I’ll still have to merge if I touched a file they touched. Yes, that's true. > What I really want to do is undo my commit, pull, and redo my commit. Then I don’t have to figure out git merge. You can do that with `git pull --rebase`, which, as others have mentioned, you can set as the default behavior of `git pull` like this: https://news.ycombinator.com/item?id=27581416 https://news.ycombinator.com/item?id=27581416