Hi Vaclav, Thanks for your detailed reply, some comments inline:
> On Tue, Apr 7, 2020 at 3:24 PM Vaclav Petras <notificati...@github.com> wrote: >> Fortunately, having Squash and merge saves the day here. Couple notes: >> >> 1. If you end up doing git pull instead of git rebase, Indeed I so far used this (for months!), in the separately checked our releasebranch78: ✘-1 ~/software/grass78_git [releasebranch_7_8 L|…7⚑ 4] 22:43 $ sh -x git_update_78.sh + git fetch --all --prune Fetching upstream Fetching origin + git checkout releasebranch_7_8 Already on 'releasebranch_7_8' + git merge upstream/releasebranch_7_8 Already up to date. + git push origin releasebranch_7_8 To github.com:neteler/grass.git ! [rejected] releasebranch_7_8 -> releasebranch_7_8 (non-fast-forward) error: failed to push some refs to 'g...@github.com:neteler/grass.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. I already trashed my fork, updated successfully, regenerated the fork and updated again, getting above troubles. As mentioned, till a few days ago no such problems. I don't know what happened. >> you can try setting git config --global pull.rebase true for git pull to be >> automatically turned into git pull --rebase. I don't have experience with >> how this plays out with the upstream+fork setup, so you need to test. >> However, the point here is that Git won't do merge unless you ask it to do >> it, well, git pull is one of the ways you are telling Git to do merge, >> although it does not seem that way. I recommend the git man page generator >> to mediate the pain from this >> (https://git-man-page-generator.lokaltog.net/#aa9b72bf4fa689dc39dc9d297f35142d). ok, trying that: git pull --rebase upstream releasebranch_7_8 From github.com:OSGeo/grass * branch releasebranch_7_8 -> FETCH_HEAD Already up to date. Current branch releasebranch_7_8 is up to date. Now, how to update in future this directory? I also want to be able to cherry-pick from master as I did since the git(hib) migration. >> 2. Squash and merge allows editing the commit message. Confirmed. This (single) time I didn't in order to preserve the different authors. >> 3. Unless you do or already did something to fix it, your releasebranch_7_8 >> (i.e., releasebranch_7_8 in the neteler fork) still contains all this and >> you need to clean it before you can backport again. (it was all clean...) >> You need to trash (assuming it's trash) what you have in your local >> releasebranch_7_8 branch and force it to be whatever the upstream state of >> the branch is. The git reset command should do the trick with these >> parameters: git reset --hard upstream/releasebranch_7_8 (related SO answer, >> https://stackoverflow.com/a/9210705/574907). You can confirm by looking at >> commits on GitHub and locally with git log. Yes, I actually did git reset --hard upstream/releasebranch_7_8 and git log. Still encountering above error. >> 4. If you are doing a PR to update any branch, you need to do that from a >> new dedicated branch in your fork. Yes, I always open a respective feature branch. >> If you don't do that, your branch (here: neteler:releasebranch_7_8) will >> diverge from the upstream one (here: OSGeo:releasebranch_7_8) and you will >> end up doing steps in number 3 in order to stop propagating the unwanted >> commits. Sure. I did that once last year (like most new-to-git-comers one time) and then learned to always start a feature branch. >> This is due to the difference between doing push directly to upstream (git >> push upstream releasebranch_7_8) which just pushes local commit(s) you have >> and PR workflow where a new commit is always created in the upstream and >> thus you don't have it locally. Yes. The things is that I just did "cherry-pick" ing. I have done so many (also for you :-) and no problem. Just recently I must have messed something up. >> As I mentioned previously on mailing list, note that the randomly generated >> Git man pages actually need to explicitly say that they are not the real >> documentation. Well, my problem is that I don't know any more what the procedure is. My workflow which was ok since last year is broken. Deleting/redoing the fork does not help. I am using this git version, if it matters: git version 2.25.1 Markus _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
