-1

In the course of reviewing PRs, I will pull down a colleague's branch. If my colleague subsequently force pushes changes to remote as a result of a rebase, when I next do a pull, I will get merge conflicts I don't want to deal with - I just want the branch as it exists remotely.

I have been doing:

git checkout master
git branch -D some-branch
git checkout some-branch

That works, but I'm sure there is probably a simpler (and lazier) way to do this.

Mister Epic
  • 16,295
  • 13
  • 76
  • 147
  • Does this answer your question? [How do I force "git pull" to overwrite local files?](https://stackoverflow.com/questions/1125968/how-do-i-force-git-pull-to-overwrite-local-files) – jonrsharpe Sep 28 '22 at 13:19

1 Answers1

1

It's simple: don't pull. Pulling implies that you have a local copy of the colleague's branch. But you don't need one. When you want to review the colleague-branch PR, just say

git fetch
git switch --det origin/colleague-branch

Now you are on the colleague's branch, and you can see the code and run it to test it out.

When the colleague makes a change and you want to see that too, guess what you say?

git fetch
git switch --det origin/colleague-branch

Ta-daaa! You now are on the new version of the colleague's branch. No pull, no merge, no conflicts, no nothing. And no unnecessary local copy that you would just need to delete later.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • The strategy I work with means that I _never_ pull any branch ever. To see what that strategy is, see my essay at https://stackoverflow.com/a/72201388/341994. – matt Sep 28 '22 at 13:27
  • From the docs on `switch`: `--detach Switch to a commit for inspection and discardable experiments.` This is exactly what I want when doing PR reviews, I didn't know they've broken out the "switching" functionality from `checkout`! Appreciate the essay as well. – Mister Epic Sep 28 '22 at 13:31
  • _"no unnecessary local copy that you would just need to delete later"_ - `/colleague-branch` is still on your machine, no? – jonrsharpe Sep 28 '22 at 13:34
  • @jonrsharpe As you know, that is merely a consequence of the `fetch`, which you would have to do anyway (`pull` does it too). The name `/blahblah` is merely a string attached to one commit. If the PR maker eventually merges this feature branch, and if that involves deleting the feature branch, the next `fetch --prune` (all my fetches are prune fetches, thanks to my config settings) will delete that string and, if this was not a true merge, that commit will be cleaned up. The _local_ copy, on the other hand, would be `colleague-branch` pure and simple, causing all the trouble. – matt Sep 28 '22 at 13:39
  • @jonrsharpe Perhaps I should say "local version" rather than "local copy". But what I'm trying to imply is that making a local branch pins the commit it points to, and all its ancestors, into place, even while the remote version, due to a rebase or whatever, can change completely, no longer containing that commit (and perhaps some of its immediate ancestors). This causes the merge conflicts the OP complains of. In effect, the OP has turned the PR branch into a _shared_ branch; that is irresponsible, because the PR maker needs to be free to change it radically, e.g. rebase it. – matt Sep 28 '22 at 13:45
  • I probably would just go with "local branch name" instead of "local copy" or "local version" to make it absolutely clear that the only thing you are saving is the branch name pointer, which I agree you probably would want to delete afterwards had you checked out the branch. – TTT Sep 28 '22 at 18:39
  • @TTT Yeah, Torek has now moved to that sort of thing; the idea is that branches don't actually exist, what exists is branch _names_. It's a struggle. :) – matt Sep 28 '22 at 18:43