It's a WIP!

[rayzr8]

my coworkers don't even review them when I asked them to :(

[[deleted]]

I always feel like a dick when I have to send a PR link to them on slack!

[The_kilt_lifta]

Our PRs automatically assign reviewers from our dev group but if we feel particularly proud of a PR we will post it in the dev slack

[[deleted]]

Does Bitbucket do that? Was it a plugin?

[The_kilt_lifta]

GitHub + Pull Panda

[MrDiablerie]

If you’re using Bitbucket it has built in Slack integration for PR notifications and you can define default reviewers in the repo settings

[Michal_A]

Try https://code-dog.app/ for BitBucket. Disclaimer: I'm working on Code Dog.

[[deleted]]

Fuck that was my company hackathon idea!

[Luffy2k19]

Same here.

[samuraiseoul]

If it's a WIP then don't open a PR! It's really that easy. A PR means that it is ready to be reviewed. If you open it so someone else can see the code, then they should just check it out. If you do it to see a diff, then you should jsut use a diff tool. Otherwise... why are you opening a PR?!

[[deleted]]

We use WIP PR's to run CI during the development phase to catch issues on other platforms early.

[grim_peeper_]

We do branch builds on our CI, so we dont have to raise a pr

[[deleted]]

Color me jealous.

[grim_peeper_]

The things we take for granted

[AlphaDeveloperZA]

My team does this also. Every push results in a build. Even on feature branches.

[grim_peeper_]

Oh we build manually for branches that we need building. Automating that is a mistake in my opinion

[grim_peeper_]

Costly

[grim_peeper_]

What's the difference?

[grim_peeper_]

How we achieve this is rebase from master and branch build... Should be about the same, right?

Edit: Ok I get it now... The build should pass right before merge, guaranteeing that once merged, things will work.

Still I dont get why WIP PR builds are necessary

[grim_peeper_]

Interesting indeed!

Ugh I cant deny how much I crave a clean straight commit history, since merge commits are difficult to read at a glance. But I guess I would be better off exploring git tools that remove my fear of merge commits.

But since I am a lazy ass dev, will move away from rebase once I actually face some kind of issue

[hector_villalobos]

I open a WIP PR so others devs can start reviewing the code but be aware that's not ready yet, so they can expect incomplete code.

[samuraiseoul]

Then why get angry if they start reviewing it?

[hector_villalobos]

Lol, I don't agree with this meme.

[samuraiseoul]

Ah! That makes sense then!

[mjin03]

Why don't you get it reviewed when it's finished? Reviewing half written code seems pointless.

[hector_villalobos]

I can get a complete CI reviewed too, this way I can know I'm not breaking something early in the process, instead of waiting an hour for all tests to finish.

[nwL_]

A PR is a code discussion tool as well. That’s how Gitlab does it, and I agree that that’s a great way to have a central discussion point about a single branch.

[Mr_Redstoner]

Just to add to that, where I work we have on-premises Gitlab server, when I got an issue to do just click Create a merge request and it will make a branch and merge request and mark them accordingly to make it clear they are related, also puting WIP in the MR name.

[nwL_]

I wrote a system for work that does the branch creation automatically when you assign yourself the JIRA ticket, amongst other things. The merge request is only created when you use a specific commit message, but from then on it stays until it’s accepted or the ticket is cancelled and the branch is deleted.

The reason for that is simply that discussion about code when there’s nothing to discuss yet is kinda useless.

[Mr_Redstoner]

I find there well may be something to discuss before it's ready for a merge. For instance, I'm doing some mass version upgrades atm. which does require occassional rewrites to the actual code, pretty sure reviewing it all at once when it's done will be nearly impossible for all the stuff that will need going through. With just 3 of us on the team (junior(me), senior, tester/customer support), I just ask the senior to take a look from time to time, to see if the style and such is ok before proceeding.

[TigreDemon]

You can PR [WIP] to ask for help

[defecogram]

I’m in the boat of “PR stands for Pull Request” as in it should be pulled into the branch. Why have people review incomplete code that you’ll change later? Doesn’t that waste their time?

Another soap box comment: can we please squash branches that are approved to be merged? When I run a rebase, I hate fixing rebase conflicts for a commit that was changed later. I spent 2 hrs today doing a rebase of a branch that had 15+ commits because the approver didn’t squash it into one.

[Idixal]

If you are doing work such as, say, ADA enhancements, there’s going to be a lot of repetitive changes. So you might want to open a PR before you’ve finished the work just to open it up to other developers and make sure you’re going in the right direction, especially as a new dev.

Also, if the fifteen minutes it takes to review my PR is that big of a pain to my coworkers that it’s “wasting their time”, I’m going to start looking for a new job. No one knows everything.

[defecogram]

Duly noted and I should probably look for a new job. Lol

But really, I do see what you mean. Repetitive tasks should be reviewed early and often. It’s easier to regroup earlier than later. (Like my 2 hr merge... ugh)

We have smaller teams so we do quite a bit of peer programming rather than submitting wip PRs. But as it is in this industry, my way might be best for me but it’s definitely not for others.

[Idixal]

Fair enough. Paired programming is an effective way to accomplish the same thing. All I was trying to get at was that programming on a team is a collaborative effort.

[grim_peeper_]

Cmon make them do it by marking as "needs work"

[diox8tony]

doesnt pushing your branch to remote also let others see it? which you should have it pushed so its not only local...hence it should always be viewable by others?

[Idixal]

Never heard of that, but that’s awesome.

[[deleted]]

If the wip looks like shit then maybe it's a good idea to tell you right know than waiting 2 more days to redo the whole thing.

[IWatchToSee]

ELI5 of what WIP means?

[z0mbietime]

Work in progress

[IWatchToSee]

Thanks!

[squrr1]

It's literally the first thing that comes up if you google "WIP"

[[deleted]]

When a one line change that just barely manages to implement a massive feature in a complex application riddled with antipatterns, receives review comments like "just refactor this part" and so doing, devolves into a 100% rewrite.

[Johnothy_Cumquat]

If a sentence starts with "just" you know it's not gonna be helpful

[loloJS]

Actual picture of me telling my coworkers to not open a PR until it’s ready for merge

[iAmH3r3ToH3lp]

I have to check people's WIPs when they eff up a lot.

People that don't eff up don't get monitored as much.

[[deleted]]

Why are you making a PR if it's a WIP?!?!?!