How to avoid git push --force to a pull request(PR)?

[Stefan Karlsson]

Hi,

On 2020-11-25 21:51, Liu, Xin wrote:
> cc hotspot-dev.
> I found that skara-dev is mainly for skara developers. my question is for general hotspot developers.
> 
> thanks,
> --lx
> 
> 
> ________________________________________
> From: Liu, Xin
> Sent: Tuesday, November 24, 2020 5:59 PM
> To: skara-dev at openjdk.java.net
> Cc: Tobias Hartmann
> Subject: How to avoid git push --force to a pull request(PR)?
> 
> Hi, Skara developers,
> 
> 
> Tobias suggested not to use force push here
> https://github.com/openjdk/jdk/pull/1073#issuecomment-726549523
> 
> 
> Sometimes, I use git push --force to a private branch, which maps to an ongoing PR.
> What I do is to update my branch to TIP, rebase my changes to it and then "git push --force" to my branch remotely.  Skara remarks the PR “force pushed ” eg. https://github.com/openjdk/jdk/pull/1179
> 
> 
> Yes, I admit that it would ruin the "incremental webrev".  I do it for the following two reasons.
> 1) the reviewing process lasts too long. I have to update the base of my private branch, or it isn't mergeable.
> Other developers may have changed the common code when you are working on your PRs, right?  /integrate will fail because of conflicts.

Trying to understand what kind of problems you are encountering. What do 
you mean with "it isn't mergeable"? Do you mean that you get a conflict? 
If so, then resolve the conflict and then complete the merge.

> 
> 2) I have to update the base because of testing.
> Openjdk now contains the sanity check workflow. https://github.com/openjdk/jdk/blob/master/.github/workflows/submit.yml
> I'd like to pass them all before integrating.  Sometimes, I run into failures but my PR is not the culprit. The build breakage and regression are usually rapidly fixed in the master branch.

For this use-case just merge master into your local PR branch, do local 
testing, push it to the PR.

> 
> I understand I can always ditch the old PR and start over, but all comments in the old PR will lose in this way.  On the side, I also feel guilty to use force push frequently.

So, I think I've recently faced the same situation as you, where I 
really wanted to rebase my local PR branch (for reasons). What I did was 
I left the local PR branch and *did not* rebase it. Instead I created a 
new branch for the same commit and rebased that, completed some more 
changes, pushed it to GitHub for others to see. Then when it was time to 
move those changes over to the PR, I merged the rebased local branch 
into the local PR branch, resolved the conflicts by accepting the 
rebased version of the patch, and then pushed the result to the PR.

This is a bit cumbersome, so I only use that approach if I really need a 
pristine/rebased branch for, say, showing others the stand-alone commit. 
Usually, I just use merge as suggested by others.

Cheers,
StefanK

> May I know if Skara has other option to help me out?
> 
> 
> I read this blog (https://julien.danjou.info/rant-about-github-pull-request-workflow-implementation/), it declares the dilemma comes from github PR mechanism.
> but that blog was 7-year-old, I am not sure that if github has sorted it out or not. Even github hasn't, is that possible to be solved by Skara?
> 
> thanks,
> --lx
> 
> 
> 
> 
>