sets the diff to ignore whitespace
Lines changed: 3
The pipeline should handle formatting. No matter how you screw it up, once you commit, it gets formatted to an agreed upon standard.
Or auto rejected when the format doesn’t fit.
deleted by creator
Yeah I think that’s what he meant. You don’t want CI editing commits.
I use pre-commit for this. It’s pretty decent. The major flaws I’ve found with it:
-
Each linter has to be in its own repo (for most linter types). So it’s not really usable for project-specific lints.
-
Doesn’t really work with e.g. pyright or pylint unless you use no third party dependencies because you need a venv set up with your dependencies installed and pre-commit (fairly reasonably) doesn’t take care of that.
Overall it’s good, with some flaws, but there’s nothing better available so you should definitely use it.
-
You can do that? How?
Pre-commit hooks is a common approach to this, so that whatever is committed gets processed. Another possibility would be to set a bot on the repo to do automated commits after human-made ones, but that can get a little noisy.
Haha! Jokes on you! It was mostly gnu makefile calls to ruby scripts!!! You’ve just broken the build a million different ways!
Joke’s* on you
(Short for “The joke is on you”.)
Had a coworker who was a bit like this. They were tasked to do one simple thing. Required a few lines of code change at most.
They end up refactoring the entire damn thing and introduced new bugs in the process.
I feel personally attacked.
Was there much value in the refactoring, like tech debt addressed?
Doesn’t matter. One concern per PR. Refactoring and tech debt are separate concerns.
You should refactor as needed as you go because refactoring cases are never gonna be prioritised.
Not with that attitude they won’t 😛
Refactoring in PRs just makes it more difficult to review. “Do these lines belong to the goal nor not?”. Also, we’re human and miss things. Adding more text to review means the chance of missing something increases.
Especially if the refactored code isn’t just refactored but modified, things are very easy to miss. Move an entire block of code from one file to another and make changes within = asking for trouble or a “LGTM” without any actual consideration. It makes code reviews more difficult, error-prone, and annoying.Code reviews aren’t there to just tick off a box. They are there to ensure what’s on the tin is actually in it and whether it was done well.
In my experience I haven’t had an issue because usually the refactorings are small. If they’re not I just hop on a call with the person who wrote the MR and ask them to walk me through it.
In theory I’d like to have time to dedicate solely to code health, but that’s not quite the situation in basically any team I’ve been in.
I haven’t had any trouble separating refactors PRs from ticket PRs. Make the ticket PR, make a refactor PR on that ticket PR, merge the ticket PR, rebase refactor PR on master, open ticket PR for review, done 🤷
There was a guy I worked with that tended to want to unilaterally make sweeping changes.
Like, “we need the user to be able to enter their location” -> “cool. Done. I also switched the dependency manager from pip to poetry”.
Only a little bit of exaggeration
Some people, like me, are not built to be developers. I can sculpt code in any language I need for whatever problem I need to solve, but maintaining code over a long period of time, with others, is not my thing.
The drive to do additional changes is just too high and the tendency for typos or obvious logic errors is too common. (There is one little improvement. It’s right there. One line up. Just change it now while you are in there…)
I am not stupid and regard myself as a decent engineer but my brain is just wired in a more chaotic way. For some things that is ok. For developing code on a team, not so much.
Security is the field I am most comfortable with because it allows for creative chaos. Rule breaking is encouraged. “Scripting” is much more applicable and temporary.
deleted by creator
I do. Also, I am old(ish) so I have had many years to come to terms with what I can do well and where I struggle.
In this case, I didn’t want to use it as a crutch or an excuse. After reading the number of awesome replies this morning, I realized I should have probably framed my comment differently.
People here put some real time and effort into giving some solid advice and I didn’t expect that.
Edit: As a pure example, this is the third or fourth edit of this comment. Words are challenging, and programming is very similar in that regard.
When using git and are working on a feature, and suddenly want to work on something else, you can use
git stashso git remembers your changes and is able to restore them when you are done. There is alsogit add -pthis allows you to stage only certain lines of a file, this allows you to keep commits to a single feature if you already did another change that you didn’t commit (this is kind of error prone, since you have to make sure that the commit includes exactly the things that you want it to include, so this solution should be avoided). But the easiest way is when you get the feeling that you have completed a certain task towards your goal and that you can move on to another task, to commit. But if you fail you can also change the history in git, so if you haven’t pushed yet, you can move the commits around or, if you really need to, edit past commits and break them into multiple.Instructions unclear. Stash is 35 tall and I’m scared to look at what’s been fermenting at the bottom.
Only 35? That’s rookie numbers.
I mean, Poetry is a lot better then Pip. The only issue I see is that they broke some CICD stuffs farther up the chain.
It could be!
But part of working as a professional on a team is communicating and achieving consensus. Just trying to make a change like that out of the blue is poor form.
Also consider the opportunity cost: we had planned on getting XYZ done this week, and instead he spent a few hours on this and dragged a few people into a “do we want to change to poetry right now?” conversation
LGTM
Let’s test in prod
As long as there’s less code than there was before, I’ll approve it
Deletes codebase
Looks about right, approved ✅
Bugs are all gone, boss
I laughed so hard at this, thanks
Net removal of 1500 LoC…
I’m gonna make you break this up into multiple PRs before reviewing, but honestly, if your refactoring reduced the surface area by 20% I’m a happy man.
it’s just removed unit tests that didn’t work any more…
😱
That’s when you set the intern’s IDE to preserve the line endings.
Love it when my coworkers reformat the code style, making it nigh impossible to understand what they actually changed, while greatly inflating their “contribution.”
It also blows away the git blame, making it hard to know who actually changed that one critical line of business logic 3 years ago that you need to understand before trying to fix some obscure bug.
I have one coworker who does this constantly and if you just looked at git blame, you’d think he wrote the entire code base himself.
First things first: Your team needs a coding style.
Also: With git reflog ignore-revs you can filter commits that only adapt the style.
And while we’re at it, check out the -C -C -C flag for git blame. https://git-scm.com/docs/git-blame#Documentation/git-blame.txt--Cltnumgt
I try to keep my changes under 300-350 lines. Seems like a good threshold.
I’m still annoyed that Github doesn’t have good support for stacked diffs. It’s still not possible to say that one PR depends on a different one, and still has no ability to review and land them as a stack.
How is this different from creating a feature branch and making your PR against them until everything is done, then merging that into the main branch?
Making PRs against a feature branch still has the same problem.
Say you’re working on a major new feature, like adding a new log in flow. It’s a good idea to split it into many small changes: create initial log in form, implement user sessions, add SSO support, add “remember me” functionality, etc.
Those changes will likely depend on each other, for example adding the “remember me” checkbox requires the form to actually be built, and you probably don’t want to wait for the reviewers to review one change before continuing your work. This means you naturally end up with PRs that depend on each other in a chain.
Stacked PRs (or stacked diffs, stacked MRs, whatever your company calls it) means that:
- The code review tool lets you specify dependencies between the PRs, for example the “remember me” PR depends on the initial login form implementation
- It shows the dependencies visually in the UI, like a chain or tree
- Changes can’t be landed until the PRs they depend on have been reviewed
- There’s a way to land an entire stack
- When you review a PR later in the stack, it doesn’t show any of the changes that were made earlier in the stack. Each PR focuses just on the changes in that part.
- For each PR, the build steps and linters run for all the changes in the stack up until that point. It helps detect if incompatible changes are made earlier in the stack.
Making all your commits directly to a branch then creating a PR for the whole branch is similar, but reviews are a nightmare since it’s only a single review for the entire branch, which can be thousands of lines of code.
At my workplace, we use feature flags (essentially
ifstatements that can be toggled on or off) rather than feature branches. Everyone works directly from the main branch. We use continuous deployment which means landed code is quickly pushed to production. New features are hidden behind a feature flag until they’re ready to roll out.You can make a PR against your feature branch and have that reviewed. Then the final PR against your man branch is indeed huge, but all the changes have already been reviewed, so it’s just LGTM and merge that bad boy!
You can make a PR against your feature branch and have that reviewed
But what if you have multiple PRs that depend on each other? Or are you saying only have one PR open at a time? That sounds like it’d be very slow?
I suppose it is possible to have two PR that have changes that depend on each other. In general this just requires refactoring… typically making a third PR removing the circular dependency.
It sounds like your policy is to keep PR around a long time, maybe? Generally we try to have ours merged within a few days, before bitrot sets in.
Sorry, my comment was unclear. I didn’t mean a circular dependency, just PRs that have a chain of dependencies (e.g. PR 100 that depends on 99, that depends on 98, that depends on 97)
They’re usually not around for a long time, but there can be relatively large chains if someone is quickly adding new features.
This does seem like a potential issue if the PR is itself implementing more than one vertical slice of a feature. Then it could have been smaller and there might be wasted effort.
If the patches are small and well-organized then this isn’t necessarily a bad thing. It will take more than one day to review it, but it clearly took much more time to write it.
True, but at the same time its very possible to go too small. A bunch of one line code reviews can really slow progress easily.
Stuffing multiple tasks into one PR is often bad.
- It’s harder to review. As a reviewer it’s difficult to know which code change is related to which task.
- It’s harder to verify. Did you really test every change you made?
- You might end up with a “hostage” situation. There might be a few code changes in the PR that looks good and is really wanted, but other code changes in the same PR of lower quality. As a reviewer, should you just let these lower quality code changes slide so you can bring in the code change you really want? Probably not, but you’re going to let it slide either way.
You might end up with a “hostage” situation.
Reminds me of a guy I used to work with.
He’d have like a pretty normal PR to do something like change a field to be read only in some API. But then snuck into the pr there’d also be something like “change application to run locally different than prod for entirely selfish reasons” or “lower global coverage requirements” or “disable type checking in this whole folder”
I also worked with a guy like that. Impossible to predict what he was going to do in his next PR. Always a nightmare to review. Also exhausting to argue with, so let some things slide because I was so done dealing with his bs.
This guy was also difficult to argue with. He was always professional, which I guess is worth something.
One time he tried to remove all the types from a bunch of code “because they were all going to change later.” I refused to allow this. We went back and forth in the comments for hours. I think eventually the lead or boss got involved. Thankfully people sided with me.
His “later” project that was allegedly going to change all the things was rejected by the team. The code in question is still used and properly typed a year later.
