<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 10, 2021 at 1:16 PM Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>...<br></div><div>$ git checkout raster_tempdir<br>$ git rebase main<br><br>Successfully rebased and updated refs/heads/raster_tempdir.<br><br>$ git status <br>On branch raster_tempdir<br>Your branch and 'metzm/raster_tempdir' have diverged,<br>and have 48 and 7 different commits each, respectively.<br>  (use "git pull" to merge the remote branch into yours)<br><br>$ git push metzm raster_tempdir<br>! [rejected]            raster_tempdir -> raster_tempdir (non-fast-forward)<br>error: failed to push some refs to 'github.com:metzm/grass.git'<br>hint: Updates were rejected because the tip of your current branch is behind<br>hint: its remote counterpart. Integrate the remote changes (e.g.<br>hint: 'git pull ...') before pushing again.<br>hint: See the 'Note about fast-forwards' in 'git push --help' for details.</div></div></blockquote><div><br></div><div>This is how it is supposed to behave when you do `git rebase`. Rebasing re-applies the changes you made in raster_tempdir one by one on top of your local main. This creates different commits in the sense that the commit hashes are different. This causes the "have diverged" part. 48 on the local raster_tmpdir is your 7 commits plus 41 commits which happened in the main branch since you created raster_tempdir. 7 commits on metzm/raster_tempdir is the original commits you made which have the original, different hash, so Git considers them to be different. <br></div><div><br></div><div>Force push with `git push -f metzm raster_tempdir` is appropriate here. You will replace whatever is in the remote branch by your newly updated (rebased) local branch content.</div><div><br></div><div>We are currently merging all PRs using the "Squash and merge" feature, this reduces the commit which will go to the main branch to only the actual changes taking care of the merge commits. So, you can use git merge or git rebase on your branches.</div><div><br></div><div>I still prefer rebase most of the time because it is easier to review commits in the PR (since there are no merge commits). Some people also use rebase to reduce the commits on a branch to one, but I think that's usually not helpful for review. However, merge does not require the strange force pushing and it works better in case of conflicts because you are simply merging the latest state, not each commit on your branch which is the case with rebase.</div><div><br></div><div>As far as I can tell, the master-main rename should not have any influence on this. And yes, the message from `git push` is not applicable here.<br></div><div><br></div></div></div>