<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 8, 2020 at 5:13 PM Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</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">Hi Vaclav,<br>
<br>
Thanks for your extensive explanations! Much appreciated.<br>
<br>
I think that I have probably found the missing part: I should have<br>
deleted the *entire* directory. By just deleting my fork and re-adding<br>
it as a "remote" I probably still had all the clutter in my local<br>
copy.<br>
<br>
Today I have<br>
- trashed the entire directory<br>
- clones the repo<br>
- deleted my fork and created it again<br>
- added the fork as a "remote"<br></blockquote><div><br></div><div>This does not sound like recommended workflow: clone fork as origin, add OSGeo as upstream. Are you aware of that?</div><div><br></div><div>Related to that, I'm not sure why most projects using this workflow use the name origin for one's own fork. Calling it fork, myfork or <username> seems more explicit. Perhaps something to consider.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Magically (well, not really), it seems to be clean.<br>
<br>
Might that be the explanation, that I didn't properly start from scratch?<br></blockquote><div><br></div><div>Since I saw old Merge... commits in your fork, they were preserved locally or in the fork and propagated through pull/fetch or push.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What might have happened:<br>...<br>
- as you guessed, I probably cherry-picked, didn't commit due to my<br>
network issues on the road, then other backports happened and I tried<br>
to push on top of that<br></blockquote><div><br></div><div>...which is hard to avoid which in turn creates the Merge... commits which we now consider unnecessary. So I updated the wiki (how to backport a single commit and made a mess sections including some explanations):<br></div><div><br></div><div><div><a href="https://trac.osgeo.org/grass/wiki/HowToGit#Backportingtoreleasebranches">https://trac.osgeo.org/grass/wiki/HowToGit#Backportingtoreleasebranches</a></div><div><br></div><div>I did not test the rebase workflow myself, but it turned out, I suggested the workflow to Anna who was successfully using it for some time now (although I think she did not get into the same situation as you did, so not really tested for that, you can test with two clones if you want).<br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Question: would the (somewhere) existing backport bot help here?<br></blockquote><div><br></div><div>The new workflow with rebase should give us now the expected behavior, so I don't think it is needed for that.<br></div><div><br></div><div>As far as automating backports, with GitHub Actions automating should be quite possible.<br></div><div><div><br></div><div><a href="https://github.com/marketplace/actions/backport-commit">https://github.com/marketplace/actions/backport-commit</a></div><div><a href="https://github.com/marketplace/actions/backporting">https://github.com/marketplace/actions/backporting</a></div><div>(and there is more)</div><div><br></div><div>For anything like that we need to spell out our backporting policies. For example, I'm just against immediate backports because I think the change needs to settle. We had several cases of immediate backport and then quick series of fixes or reverts which does not seem right as it lowers the stability of a the stable branch. I don't see a setting of a delay in settings of the above actions which would make me happy. Using two labels one for humans and another for the bot would work in the same way without the possibly confusing delay and including some human consideration. Anyway, my point is that it is possible, but it requires more research. On top of that, the GitHub Actions (both the infrastructure and the available actions) are a moving target.<br></div><div><br></div><div>Vaclav<br></div><div></div></div></div></div>