I've used git-bug[1] for issues and it works pretty well. The web-ui is lagging behind and PR support would be everything you'd need to ditch a central-hosted web instance.
I really wish this weren't the case, but I'm afraid that we're heading to a place where if we flood reports to officials, they'll just jump on calling bike lanes "DEI" and take them out.
Depends on the city. In Philadelphia, the opposite thing happened: proposed bike lanes along half of Washington Ave. were blocked by a city council member on the grounds that "only white people ride bikes" and "bike lanes cause gentrification." It was touted as an "equity win."
This councilmember is now the President of the Philadelphia City Council.
I also like that the article uses whatever system emoji you have, so everything is just showing apple emoji in text for me. All I see are a few 3D video renders of theirs.
Can someone explain the actual use-case here? I'm struggling with this because it also hides the message from myself, making it incredibly hard to type because I have no confirmation that I hit the right keys on the keyboard.
`git history split` is really going to help me help juniors break up their large PRs into smaller more concise changes. If only it had the option to split an entire branch in two easily.
Maybe the issue is they think of a PR as an expensive thing. Would be best if they could just do the small thing and make a PR of that from the get-go. If they want to base future changes on the ones they just did, they can just create a new feature branch from right there, and just not create the PR of the second feature until the first is merged, or create it and add a note to the reviewer that it includes the changes of the other PR so they should review that one first. Should they want to add changes to the first feature, they just need to checkout that branch, do the changes, and merge to the second feature branch so they're available there.
It's expensive when you factor in each PR having to wait for someone to come and review it - it's easier to get your work done in larger PRs when that's the case, although it's a perverse incentive
Even with low review turnaround, having each PR get to a defined "goal" makes it clear if the early commits that prepare the co-debase for the goal are going in the right direction. If they were submitted as individual PRs the reviewer can only check that they don't break things but has to trust the submitter that the design is right for what will follow.
I mean, that's a positive feedback loop. It takes longer to review, because they're expecting them to be big. Big PRs/MRs are left there until there's a big enough free time block to tackle and discuss. If the PRs are small, obvious things, they can be merged in minutes.
(Depending on what the PR's about and how the team organizes. Ideally, there's consensus on the goals or who's responsible for what. Reviews can be limited to finding bugs and e.g. organizational problems)
Small stacked PRs are a NIGHTMARE unless your org is consistently turning around PRs in low single digit hours, and team members are working on decoupled code so you don't have any stack weaving. You end up in a situation where the engineering director and some tech leads really like tools like Graphite, while the entire team working under them mutters irately under their breath daily.
Probably to take a series of commits and decide "this one goes on branch A, this one on branch B", e.g. if you intermingled fixing bug A and B in the same branch, you could more easily go through and assign each commit to a new branch.
The existing workflow for that would be (there are several possible workflows, but this is what I would do):
git checkout intermingled-branch
git branch bugfix-A
git branch bugfix-B
git checkout bugfix-A
git rebase -i
# Edit the file, keep commits that fix bug A, drop commits that fix bug B
git push origin bugfix-A:bugfix-A
git checkout bugfix-B
git rebase -i
# Edit the file, keep commits that fix bug B, drop commits that fix bug A
git push origin bugfix-B:bugfix-B
Fun fact, you can also automate more of that existing workflow with the rebase interactive TODO list. Roughly something like:
pick $ACOMMIT1
edit $ABMIXEDCOMMIT # split out A parts
pick $ACOMMIT2
exec make test # test everything compiles
update-ref bugfix/A
exec git switch --detach main # new branch point
pick $BCOMMIT1
edit $ABMIXEDCOMMIT # split out B parts
pick $BCOMMIT2
exec make test
update-ref bugfix/B
exec git merge bugfix/A
pick $FOLLOWUPCOMMIT
exec make test
update-ref intermingled-branch # or bugfix/C
It's been a while since I've attempted a rebase TODO list that wild, so I may have forgotten something, but rebase interactive is pretty wild what it will let you try to automate.
I closed the page and gave up figuring out what this was about because of the poor contrast ratio and tiny font.
[edit] apparently the contrast ratio is technically okay. But this is one of those cases where raw contrast ratio isn't actually a good measure of accessibility. Just because some text has 5.92:1 contrast ratio, doesn't mean that at 11px font-size it's legible.
reply