|
Hammerite posted:For each migration script I have done several test runs to refine and re-refine the parameters*, so yes.
|
# ? Apr 27, 2021 17:56 |
|
|
# ? Jun 6, 2024 03:00 |
|
Xarn posted:rip Hey, Azure DevOps is mostly good. Unless you're saying "rip because it will be deprecated and replaced by GitHub", in which case, yeah.
|
# ? Apr 28, 2021 08:28 |
|
Kinda both. I've been using ADO at MS for the last three months, compared to GitHub/GitLab (what I used previously), it has weird limitations and lovely web frontend. e.g. why the gently caress is there like a 4k characters limit on PR description? Why is my browser slowly dying when there are ~15 open comments on a PR? I've also had to deal with the "comment targetting" (which lines of code it shows as context for PR comment) getting broken until I refreshed... that was an interesting conversation
|
# ? Apr 28, 2021 10:16 |
|
Xarn posted:Kinda both. I've been using ADO at MS for the last three months, compared to GitHub/GitLab (what I used previously), it has weird limitations and lovely web frontend. Well that sounds useless, how am I supposed to submit a pr without the complete text of finnegans wake
|
# ? Apr 28, 2021 11:36 |
|
Soricidus posted:Well that sounds useless, how am I supposed to submit a pr without the complete text of finnegans wake quote:Fixes #435
|
# ? Apr 28, 2021 11:44 |
|
Soricidus posted:Well that sounds useless, how am I supposed to submit a pr without the complete text of finnegans wake Right, I forgot that all PR descriptions are supposed to be "fixed some poo poo, maybe it works now".
|
# ? Apr 28, 2021 12:23 |
|
Why not just link the relevant work items to the pr, instead of writing a novel in the description.
|
# ? Apr 28, 2021 12:29 |
|
"This PR adds a visualization script for X. <insert image of what the visualization looks like> This PR needs followups: * X to handle cases when Ys overlap with Zs * Q to handle when we are missing data on P * F because G said they might need it in the future * B to allow using this from D environment * Also there is talk about removing library L from secured machines, we might need to migrate to K" and you will hit the limit easily. For bonus points, the attached image url counts too (not surprisingly), and changes between draft PR and submitted PR, so if you are just under the limit, you will be significantly over the limit after submitting the PR and won't be able to edit the description without significant rewrite.
|
# ? Apr 28, 2021 12:44 |
|
I've worked in Azure DevOps things while moonlighting for other teams and I don't really see the length limit as a problem. I seldom hit it - maybe once or twice so far - and if I do, I summarise and direct the reader to the work item (identified explicitly by number). The given example of "needs followups" in particular - I guess there's nothing wrong with that being in a commit description but it shouldn't be only there; it belongs in other communications too. Those followup actions are all things that would be in your backlog/project plan/team's collective brains/whatever.
|
# ? Apr 28, 2021 13:00 |
|
Xarn posted:"This PR adds a visualization script for X. so there's this language feature present in most programming languages you might not be familiar with, it's called a comment..
|
# ? Apr 28, 2021 13:00 |
|
You aren’t ever going to convince a user that the weird way they are using a tool isn’t the best and only way to use it.
|
# ? Apr 28, 2021 13:13 |
|
Why would you use a decentralized VCS and then store your discussion history on the part of it that isn't backed up or distributed?
|
# ? Apr 28, 2021 13:15 |
|
Hammerite posted:I've worked in Azure DevOps things while moonlighting for other teams and I don't really see the length limit as a problem. I seldom hit it - maybe once or twice so far - and if I do, I summarise and direct the reader to the work item (identified explicitly by number). Right, but if you outline them, then someone who is reviewing the PR has to suddenly click through and read n different pages, rather than reading the description proper. It is not terrible solution, but it is worse solution than, say, having whatever limit GH has (I've never hit, nor heard of anyone hitting it. In comparison, I know several people at my team have ran into the limit with ADO). quote:The given example of "needs followups" in particular - I guess there's nothing wrong with that being in a commit description but it shouldn't be only there; it belongs in other communications too. Those followup actions are all things that would be in your backlog/project plan/team's collective brains/whatever. They should be in PR description so that your reviewers don't open review comments about them. If your reviewers can't tell that there are pieces missing, get better reviewers
|
# ? Apr 28, 2021 13:16 |
|
Xarn posted:Kinda both. I've been using ADO at MS for the last three months, compared to GitHub/GitLab (what I used previously), it has weird limitations and lovely web frontend.
|
# ? Apr 28, 2021 13:58 |
|
LOOK I AM A TURTLE posted:Unless you're saying "rip because it will be deprecated and replaced by GitHub", in which case, yeah. Xarn posted:e.g. why the gently caress is there like a 4k characters limit on PR description? Probably backed by a varchar(max) column.
|
# ? Apr 28, 2021 16:01 |
|
i write huge PR descriptions because when people `git blame` their way through figuring out what the gently caress happened via GitHub, they tend to look more to PRs than JIRA tickets, because GitHub PRs take about a second to load while JIRA takes like seven also for code reviews! no one loving clicks the JIRA ticket when doing a code review. all of our PMs suck and write terrible AC anyways so even if you did you probably wouldn't be able to understand what the gently caress is happening
|
# ? Apr 28, 2021 17:16 |
|
abraham linksys posted:i write huge PR descriptions because when people `git blame` their way through figuring out what the gently caress happened via GitHub, they tend to look more to PRs than JIRA tickets, because GitHub PRs take about a second to load while JIRA takes like seven I think the point is that you just put it in the commit messages, so it shows up directly in git blame...
|
# ? Apr 28, 2021 17:20 |
|
we do squash-merges so every individual commit on main has an associated PR anyways if github could automatically pull the PR description into the commit message that'd be nice, but the way git/github handle commit messages is stupid as gently caress anyways, so that ship has sailed
|
# ? Apr 28, 2021 17:25 |
|
abraham linksys posted:if github could automatically pull the PR description into the commit message that'd be nice, but the way git/github handle commit messages is stupid as gently caress anyways, so that ship has sailed It can for squash merges, I think? It's a fairly recent setting.
|
# ? Apr 28, 2021 17:41 |
|
abraham linksys posted:we do squash-merges so every individual commit on main has an associated PR anyways MS is the first place where I was on team that uses squash merges, and I am not a fan tbh. Turns out that you can't just fix bad commit discipline by squash merging, because while you might end up with okay commit messages, your commits are now HUMONGOUS.
|
# ? Apr 28, 2021 17:42 |
|
Xarn posted:MS is the first place where I was on team that uses squash merges, and I am not a fan tbh. Turns out that you can't just fix bad commit discipline by squash merging, because while you might end up with okay commit messages, your commits are now HUMONGOUS. Oh, no... Do I have this?
|
# ? Apr 28, 2021 17:43 |
|
necrotic posted:It can for squash merges, I think? It's a fairly recent setting. AFAIK unless there's a buried setting, squash merges just have a default commit message of "the commit message from every commit in the branch." Which makes sense because GitHub doesn't render commit messages as markdown, so just pulling a PR description into a git message would make it harder to read (not to mention not include hyperlinks or images...). There's a world where GitHub just renders commit messages as Markdown, shows you commit message details in the PR more visibly, and people make tooling for Git that can render Markdown, and then I never write a long PR description again (outside of maybe reviewer notes & remaining TODOs) and all of that history lives inside Git instead of GitHub as it should. Unfortunately that's not the world we live in Xarn posted:MS is the first place where I was on team that uses squash merges, and I am not a fan tbh. Turns out that you can't just fix bad commit discipline by squash merging, because while you might end up with okay commit messages, your commits are now HUMONGOUS. It's weird, I started up a new repo for a new project and while I've encouraged the engineers I've been working with to use squash-merges for messy branches, I've been debating whether to disable regular merges entirely like we do on our other repos. I personally like to rebase and fixup and all that poo poo (one of my coworkers has a really good workflow for this I need to figure out; something about using "git am" as like a cherry-pick on steroids?) and make a bunch of individual clean commits, but I'd much prefer squash commits for 80% of the feature branches I've seen. It does make the commits loving huge, especially on the frontend projects I work on where there's a lot of refactor churn and a lot of large feature branches due to the difficulty of doing feature-flagged releases for large-scale changes. That said, the flipside of this is that when something inevitably breaks in a massive merged change, it's very easy to do a git revert against the one squashed commit abraham linksys fucked around with this message at 17:53 on Apr 28, 2021 |
# ? Apr 28, 2021 17:50 |
|
I just never need to see another commit with the commit message “addressed PR comments”.
|
# ? Apr 28, 2021 18:00 |
|
git commit --fixup hash git rebase -i --autosquash master 99% of the reasons I'd use squash merge just disappeared, the last 1% is that one coworker terminally unable to write commit message to save his life, where you just write non poo poo commit message for him on merge
|
# ? Apr 28, 2021 20:51 |
|
I enforce good commit messages with proper grammar and spelling. We have a corporate grammarly account for everybody, USE IT. Commit messages better drat well tell me the what and why’s of what changed.
|
# ? Apr 29, 2021 16:10 |
|
More and more I realize that fossil had the right idea with bundling everything into the repo: commits, yes, but also bug tracking, wiki, even forums.
|
# ? Apr 29, 2021 16:34 |
|
pokeyman posted:More and more I realize that fossil had the right idea with bundling everything into the repo: commits, yes, but also bug tracking, wiki, even forums. All of its stuff functions adequately enough while maintaining the ability to customize while being a giant pain to customize. It's real good I wish it won the dvcs wars.
|
# ? Apr 29, 2021 20:00 |
|
I've always thought that git commit messages should be like mini-branches in themselves, so you could push changes to old commit messages if a need arises There's no way that this could cause any kind of complications, imo Munkeymon posted:Probably backed by a varchar(max) column. Varchar(MAX) is several gigabytes in mssql, I know this because of... reasons
|
# ? Apr 30, 2021 20:13 |
|
Obfuscation posted:Varchar(MAX) is several gigabytes in mssql, I know this because of... reasons Several being two in this case.
|
# ? Apr 30, 2021 20:20 |
|
Obfuscation posted:I've always thought that git commit messages should be like mini-branches in themselves, so you could push changes to old commit messages if a need arises Perforce lets you edit changelist descriptions after they're committed. It's abusable I guess, but the only things I've ever seen it used for are: fixing typos/mistakes in the description, or having CI/build system add tags/build info.
|
# ? Apr 30, 2021 20:54 |
|
The best commits are the ones from friday at 5, that just say "fixed a bug, im going home!"
|
# ? May 1, 2021 13:01 |
|
https://twitter.com/mycoliza/status/1388287273012060162 https://twitter.com/mycoliza/status/1388289412002242563
|
# ? May 1, 2021 17:49 |
|
Selklubber posted:The best commits are the ones from friday at 5, that just say "fixed a bug, im going home!" Wrong, the best messages are the ones that say "ok now it works" because half the time that's not even totally true.
|
# ? May 2, 2021 03:57 |
|
Volmarias posted:Wrong, the best messages are the ones that say "ok now it works" because half the time that's not even totally true. "now it works(on my machine(because of changes I didn't submit(and also I didn't fully rebuild so it didn't catch a compile-time error)))"
|
# ? May 2, 2021 04:04 |
|
Absurd Alhazred posted:"now it works(on my machine(because of changes I didn't submit(and also I didn't fully rebuild so it didn't catch a compile-time error)))" The couple times a year when I do that last one, I immediately spend an hour making the build faster in penance.
|
# ? May 2, 2021 05:09 |
|
pokeyman posted:The couple times a year when I do that last one, I immediately spend an hour making the build faster in penance. What’s faster than not running the build?
|
# ? May 2, 2021 16:21 |
|
csammis posted:What’s faster than not running the build? The angry horde of coworkers who just realized the build is broken.
|
# ? May 2, 2021 23:08 |
|
Absurd Alhazred posted:"now it works(on my machine(because of changes I didn't submit(and also I didn't fully rebuild so it didn't catch a compile-time error)))" Good thing you use CI and the commit never made it anywhere important.
|
# ? May 3, 2021 07:31 |
|
ultrafilter posted:https://twitter.com/mycoliza/status/1388287273012060162 Functioning link: https://engineering.virginia.edu/news/2021/04/defenseless-uva-engineering-computer-scientists-discover-vulnerability-affecting Paper: https://www.cs.virginia.edu/venkat/papers/isca2021a.pdf
|
# ? May 3, 2021 08:06 |
|
|
# ? Jun 6, 2024 03:00 |
|
It seems plainly intuitive that you can't have speculative execution that's worth anything without also leaking data on side channels
|
# ? May 3, 2021 13:05 |