I think people worry too much about branch names. Feature branches are usually ephemeral. Prefix your branch with your personal identifier so I know who is primary on it and worry more about the commit message which will live on indefinitely.
I have a little script that does this automatically - lists out Jira tickets assigned to me, then when I select one, creates a branch with the ticket number and the title, subbing hyphens for spaces and truncating if needed. It’s handy for when I want to list branches, I can filter on keywords I remember from the ticket name.
That's been my preference at most places I've worked. issue id so the branch gets linked to jira or whatever and a short description to find the branch later if needed.
A nice benefit of prefixing by your-name/issue-1234-some-description is that many git clients will show it in a folder structure that way and it's easy to differentiate yours from other branches.
having feature/username/id-desc is good though. Because at least you can identify why the branch is there. That they are ephemeral doesn't mean that people actually clean them up...
I understand, but that means you need to review the commits and code changes and do not have the context which could be found either in the issue title, description, etc.
This would infuriate me. You have to index that guid to something yourself. Why wouldn't you at least give yourself some help (your name, issue number, type of change, area of project, etc). Why make your job harder than it needs to be?
Hard disagree here. GitHub does encourage this sort of thing, but even there for my PRs to be easily reviewable, I like to keep my commits organized and with good messages explaining things. That way the reviewer can walk the commits, and see why each thing was thing was done.
I also like it for myself, when I’m going over my own PRs before asking for a review - I will often amend commits to ensure the work is broken down correctly, each thing that should go together, does.
In a way, stacked PRs are just a higher-level abstraction of this too - same idea, keep work that goes together in the same place.
Fully agree with you here. Blunt squashing is a bandaid to the problem of lazy commits. Commits should IMHO be specific and atomic. Like fixing one bug or implementing one feature. Obviously there are cases where this ideal isn't practical, but the answer is still not squash everything, it's to think for 10 more seconds about the commit and do your best.
Yeah, I think over use of GitHub, which seems to encourage squash-merging, has led to this where a lot of people I’ve seen treat a PR as essentially one commit - because it ends up being one in the end.
If you keep your PRs small I guess the end result is the same, but even then I like things in individual commits for ease of review.
I want to see detailed atomic commits during PR review, and once it's reviewed I'm happy to have it squashed. If the PR produces so much code/changes that main branch needs detailed atomic commits for future reference, then the PR was too large to begin with, imo.
I do agree that this is a good compromise. For me, if I do a git blame and eventually can find the PR that led to change, if it has nice clean commits, that’s good enough.
Its not a if. it's necessary for the sake of people reviewing your code.
Unless you work alone on your pet project and always push to master you never work alone.
The argument I've always heard for this was issues with code, not the event. If for a period of time you have a bug in your code, with event sourcing, you can fix the bug and replay all the events to correct current projections of state.
Agree, in fact this wonderful book calls this out, stating:
As DuckDB is an analytics database, it has only minimal support for transactions and parallel write access. You therefore couldn’t use it in applications and APIs that process and store input data arriving arbitrarily. Similarly when multiple concurrent processes read from a writeable database.
You are basically saying "Don't use any native apps, ever". With chrome profiles, links are just opened in whatever profile window was last active (this is on Mac OS, but I think others are the same). It's the one thing keeping me with chrome (brave).
I'd be glad to, but I'm not sure yet how helpful it would be to do so here, without just sharing the full spreadsheet. Which I would need to clean up and anonymize first. It may be very particular to my needs. I drew inspiration from many other "YNAB spreadsheets" (searching reddit etc.) I can say that learning the SUMIFS formula to sum the relevant transactions for a given envelope was a big key to making it work well. The other details are polish around it. I'm afraid that this might not come across very clear. I found that the more that I desired a certain feature and searched for how to do it in Excel or Google Sheets (or Libre Calc, but there is less specific resources for that) then it gave me the next bit that I needed.
My problem is opening links from apps. Sometimes I want a link in Slack (or other desktop apps) to open in my personal profile and sometimes I want it to use my work profile. With Brave/Chrome, the link will open in whatever profile window is active. I can't find a way to make this work with Firefox.
This is years ago now, but every ampersand in my passwords came across wrong. I can't recall if it was missing or url encoded, but even passwords weren't safe.
I want to as well, but annoyingly there are many sites that insist on a "special" character because their strength measure says "low" for the 20 character alphanumeric string I generated %-}
My favorite is when they actually limit what special characters you can use. Must include 1 of x special characters. Why? I always just assume they baked their own password storage and couldn't figure out how to handle the whole set of special characters
Multiple times I've found that this is caused by a web application firewall that is intended to mitigate SQL injection attacks. So they disallow the characters that would commonly be used in those attacks.
On those sites, I generally insert the same fixed uppercase-and-symbol string on my zbase32ed-entropy passwords. Zbase32 tends to produce numbers already, and that combo tends to satisfy the silly sites.
