[GRASS-dev] Backport sync: merge mess

[Markus Neteler]

Hi Vaclav,

Thanks for your detailed reply, some comments inline:

> On Tue, Apr 7, 2020 at 3:24 PM Vaclav Petras <notifications at 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 'git at 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