Question: how do you make a PR that included WIP in a commit no longer a WIP

[bradical]

Is there some way in a later commit to tell it that it's no longer a WIP?

[gr2m]

Thanks for opening the issue, that’s a very good question, I think we should address it in the README and the app’s description.

You’ll have to update the commits for the pull request. You usually do that locally on your machine and then git push -f to the branch of the pull request. There are some tutorials out there, my fav is https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github, the final chapters are about cleaning up the commit history of a pull request

[bradical]

Got it. I'm familiar with that process. So basically have to get any commits with WIP out of the PR. Sounds like Labels and Titles are the way to go then for ease of use. Unless you're working on something that you're quite sure will always be a WIP (e.g. disposable prototype) and want to make it difficult to convert to non-WIP.

…

On Thu, Mar 8, 2018 at 11:55 AM Gregor Martynus ***@***.***> wrote: Thanks for opening the issue, that’s a very good question, I think we should address it in the README and the app’s description. You’ll have to update the commits for the pull request. You usually do that locally on your machine and then git push -f to the branch of the pull request. There are some tutorials out there, my fav is https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github, the final chapters are about cleaning up the commit history of a pull request — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALqnKLPNujzrpjMcA6LokMnvbiInmJTks5tcWKIgaJpZM4Si_C6> .

[mwarkentin]

Yeah, it'd be nice if there was a way to disable the check on commit messages. Having to tell developers that they need to rebase their commits (some may not be comfortable with rewriting git history, etc) isn't great (especially for what is otherwise a very simple low overhead tool).

[bradical]

Any reason not to use the label or title in that case? Seems easy to add and easy to change.

…

On Wed, Mar 14, 2018 at 12:59 Michael Warkentin ***@***.***> wrote: Yeah, it'd be nice if there was a way to disable the check on commit messages. Having to tell developers that they need to rebase their commits (some may not be comfortable with rewriting git history, etc) isn't great (especially for what is otherwise a very simple low overhead tool). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALqnGQCMkg1BBy2Pa4Kn7CyfR8OYztfks5teUxvgaJpZM4Si_C6> .

[gr2m]

Having to tell developers that they need to rebase their commits (some may not be comfortable with rewriting git history, etc) isn't great (especially for what is otherwise a very simple low overhead tool).

You don’t have to, you can use GitHub’s "squash & merge" button. The WIP App setting the status to "pending" will then just serve as a reminder to not accidentally merge it with the other two options.

Does that work for you?

[gr2m]

An alternative would be to remove the check in commit messages entirely, I would not make it configurable in order to keep the WIP bot as simple as it is right now

[mwarkentin]

@gr2m squash and merge is subject to the same branch protection configs as the other types of merges isn't it? So developers would still be blocked if we've configured it that way?

I would be 👍 to removing the check from commit messages, but I know that was originally requested by other people. Maybe worth a poll or similar to see how people feel about it?

[bradical]

Can you just not use it organizationally and instead rely on the labels and issue titles? What's the harm in keeping it in the tool?

…

On Wed, Mar 14, 2018 at 5:00 PM Michael Warkentin ***@***.***> wrote: @gr2m <https://github.com/gr2m> squash and merge is subject to the same branch protection configs as the other types of merges isn't it? So developers would still be blocked if we've configured it that way? I would be 👍 to removing the check from commit messages, but I know that was originally requested by other people. Maybe worth a poll or similar to see how people feel about it? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALqnOuTkRqIX0aW6qnAd8slzByxC2isks5teYTbgaJpZM4Si_C6> .

[gr2m]

squash and merge is subject to the same branch protection configs as the other types of merges isn't it? So developers would still be blocked if we've configured it that way?

ah yes of course, sorry I am mostly an admin on the repos I maintain so I can get around that.

Can you just not use it organizationally and instead rely on the labels and
issue titles? What's the harm in keeping it in the tool?

I’m not sure what you mean exactly? How would you tell the WIP bot to set the state to success if there are still WIP commits on the PR?

[bradical]

I’m not sure what you mean exactly? How would you tell the WIP bot to set the state to success if there are still WIP commits on the PR?

I guess I’m saying don’t use commits to indicate WIP ever and instead using titles/labels. That way you won't have to worry about trying to unset the status via commit later.

[gr2m]

yeah I’m thinking of doing that.

[FranklinYu]

Typically a WIP commit should always be the last commit (e.g. synchronizing between machines), and later be --amended. Having WIP commits merged to master seems wrong to me. Commits should be atomic, i.e. any commit should work on its own.

[panmona]

I have a commit in this pull that states that it is a work in progress design (commit is atomic though). Not so great that this makes the thing not mergable (without admin rights)

I'm either for disabling that check OR when you add a wip-ignore label (or similar) to the pull it will make it mergable.

[rpetrusha]

I can understand making a PR a work in progress when a commit message includes "work in progress" or something similar. But the WIP check should only look at the most recent commit message and, if it doesn't include the phrase, allow the PR to be merged.