Expand Cut Tags

No cut tags

Self-satisfaction

Sep. 11th, 2025 12:09 am
mecurtin: face of tuxedo tabby cat Purrcy looking smugly happy (purrcy face)
[personal profile] mecurtin
When Purrcy is very happy to be next to a human he sits upright on his butt like a little guy, spreads his legs, & prepares to lick his belly & otherwise have a good time. He is extremely vulgar & the envy of all human males, I'm informed.

Purrcy the tuxedo tabby is sitting up like a human with a kind of dopey expressing on his face. Trust me, I've chosen the camera angle carefully.

first-class merges and cover letters

Sep. 11th, 2025 02:38 am
fanf: (Default)
[personal profile] fanf

https://dotat.at/@/2025-09-11-cover-letter.html

Although it looks really good, I have not yet tried the Jujutsu (jj) version control system, mainly because it's not yet clearly superior to Magit. But I have been following jj discussions with great interest.

One of the things that jj has not yet tackled is how to do better than git refs / branches / tags. As I underestand it, jj currently has something like Mercurial bookmarks, which are more like raw git ref plumbing than a high-level porcelain feature. In particular, jj lacks signed or annotated tags, and it doesn't have branch names that always automatically refer to the tip.

This is clearly a temporary state of affairs because jj is still incomplete and under development and these gaps are going to be filled. But the discussions have led me to think about how git's branches are unsatisfactory, and what could be done to improve them.

branch

One of the huge improvements in git compared to Subversion was git's support for merges. Subversion proudly advertised its support for lightweight branches, but a branch is not very useful if you can't merge it: an un-mergeable branch is not a tool you can use to help with work-in-progress development.

The point of this anecdote is to illustrate that rather than trying to make branches better, we should try to make merges better and branches will get better as a consequence.

Let's consider a few common workflows and how git makes them all unsatisfactory in various ways. Skip to cover letters and previous branch below where I eventually get to the point.

merge

A basic merge workflow is,

  • create a feature branch
  • hack, hack, review, hack, approve
  • merge back to the trunk

The main problem is when it comes to the merge, there may be conflicts due to concurrent work on the trunk.

Git encourages you to resolve conflicts while creating the merge commit, which tends to bypass the normal review process. Git also gives you an ugly useless canned commit message for merges, that hides what you did to resolve the conflicts.

If the feature branch is a linear record of the work then it can be cluttered with commits to address comments from reviewers and to fix mistakes. Some people like an accurate record of the history, but others prefer the repository to contain clean logical changes that will make sense in years to come, keeping the clutter in the code review system.

rebase

A rebase-oriented workflow deals with the problems of the merge workflow but introduces new problems.

Primarily, rebasing is intended to produce a tidy logical commit history. And when a feature branch is rebased onto the trunk before it is merged, a simple fast-forward check makes it trivial to verify that the merge will be clean (whether it uses separate merge commit or directly fast-forwards the trunk).

However, it's hard to compare the state of the feature branch before and after the rebase. The current and previous tips of the branch (amongst other clutter) are recorded in the reflog of the person who did the rebase, but they can't share their reflog. A force-push erases the previous branch from the server.

Git forges sometimes make it possible to compare a branch before and after a rebase, but it's usually very inconvenient, which makes it hard to see if review comments have been addressed. And a reviewer can't fetch past versions of the branch from the server to review them locally.

You can mitigate these problems by adding commits in --autosquash format, and delay rebasing until just before merge. However that reintroduces the problem of merge conflicts: if the autosquash doesn't apply cleanly the branch should have another round of review to make sure the conflicts were resolved OK.

squash

When the trunk consists of a sequence of merge commits, the --first-parent log is very uninformative.

A common way to make the history of the trunk more informative, and deal with the problems of cluttered feature branches and poor rebase support, is to squash the feature branch into a single commit on the trunk instead of mergeing.

This encourages merge requests to be roughly the size of one commit, which is arguably a good thing. However, it can be uncomfortably confining for larger features, or cause extra busy-work co-ordinating changes across multiple merge requests.

And squashed feature branches have the same merge conflict problem as rebase --autosquash.

fork

Feature branches can't always be short-lived. In the past I have maintained local hacks that were used in production but were not (not yet?) suitable to submit upstream.

I have tried keeping a stack of these local patches on a git branch that gets rebased onto each upstream release. With this setup the problem of reviewing successive versions of a merge request becomes the bigger problem of keeping track of how the stack of patches evolved over longer periods of time.

cover letters

Cover letters are common in the email patch workflow that predates git, and they are supported by git format-patch. Github and other forges have a webby version of the cover letter: the message that starts off a pull request or merge request.

In git, cover letters are second-class citizens: they aren't stored in the repository. But many of the problems I outlined above have neat solutions if cover letters become first-class citizens, with a Jujutsu twist.

  • A first-class cover letter starts off as a prototype for a merge request, and becomes the eventual merge commit.

    Instead of unhelpful auto-generated merge commits, you get helpful and informative messages. No extra work is needed since we're already writing cover letters.

    Good merge commit messages make good --first-parent logs.

  • The cover letter subject line works as a branch name. No more need to invent filename-compatible branch names!

    Jujutsu doesn't make you name branches, giving them random names instead. It shows the subject line of the topmost commit as a reminder of what the branch is for. If there's an explicit cover letter the subject line will be a better summary of the branch as a whole.

    I often find the last commit on a branch is some post-feature cleanup, and that kind of commit has a subject line that is never a good summary of its feature branch.

  • As a prototype for the merge commit, the cover letter can contain the resolution of all the merge conflicts in a way that can be shared and reviewed.

    In Jujutsu, where conflicts are first class, the cover letter commit can contain unresolved conflicts: you don't have to clean them up when creating the merge, you can leave that job until later.

    If you can share a prototype of your merge commit, then it becomes possible for your collaborators to review any merge conflicts and how you resolved them.

To distinguish a cover letter from a merge commit object, a cover letter object has a "target" header which is a special kind of parent header. A cover letter also has a normal parent commit header that refers to earlier commits in the feature branch. The target is what will become the first parent of the eventual merge commit.

previous branch

The other ingredient is to add a "previous branch" header, another special kind of parent commit header. The previous branch header refers to an older version of the cover letter and, transitively, an older version of the whole feature branch.

Typically the previous branch header will match the last shared version of the branch, i.e. the commit hash of the server's copy of the feature branch.

The previous branch header isn't changed during normal work on the feature branch. As the branch is revised and rebased, the commit hash of the cover letter will change fairly frequently. These changes are recorded in git's reflog or jj's oplog, but not in the "previous branch" chain.

You can use the previous branch chain to examine diffs between versions of the feature branch as a whole. If commits have Gerrit-style or jj-style change-IDs then it's fairly easy to find and compare previous versions of an individual commit.

The previous branch header supports interdiff code review, or allows you to retain past iterations of a patch series.

workflow

Here are some sketchy notes on how these features might work in practice.

One way to use cover letters is jj-style, where it's convenient to edit commits that aren't at the tip of a branch, and easy to reshuffle commits so that a branch has a deliberate narrative.

  • When you create a new feature branch, it starts off as an empty cover letter with both target and parent pointing at the same commit.

  • Alternatively, you might start a branch ad hoc, and later cap it with a cover letter.

  • If this is a small change and rebase + fast-forward is allowed, you can edit the "cover letter" to contain the whole change.

  • Otherwise, you can hack on the branch any which way. Shuffle the commits that should be part of the merge request so that they occur before the cover letter, and edit the cover letter to summarize the preceding commits.

  • When you first push the branch, there's (still) no need to give it a name: the server can see that this is (probably) going to be a new merge request because the top commit has a target branch and its change-ID doesn't match an existing merge request.

  • Also when you push, your client automatically creates a new instance of your cover letter, adding a "previous branch" header to indicate that the old version was shared. The commits on the branch that were pushed are now immutable; rebases and edits affect the new version of the branch.

  • During review there will typically be multiple iterations of the branch to address feedback. The chain of previous branch headers allows reviewers to see how commits were changed to address feedback, interdiff style.

  • The branch can be merged when the target header matches the current trunk and there are no conflicts left to resolve.

When the time comes to merge the branch, there are several options:

  • For a merge workflow, the cover letter is used to make a new commit on the trunk, changing the target header into the first parent commit, and dropping the previous branch header.

  • Or, if you like to preserve more history, the previous branch chain can be retained.

  • Or you can drop the cover letter and fast foward the branch on to the trunk.

  • Or you can squash the branch on to the trunk, using the cover letter as the commit message.

questions

This is a fairly rough idea: I'm sure that some of the details won't work in practice without a lot of careful work on compatibility and deployability.

  • Do the new commit headers ("target" and "previous branch") need to be headers?

  • What are the compatibility issues with adding new headers that refer to other commits?

  • How would a server handle a push of an unnamed branch? How could someone else pull a copy of it?

  • How feasible is it to use cover letter subject lines instead of branch names?

  • The previous branch header is doing a similar job to a remote tracking branch. Is there an opportunity to simplify how we keep a local cache of the server state?

Despite all that, I think something along these lines could make branches / reviews / reworks / merges less awkward. How you merge should me a matter of your project's preferred style, without interference from technical limitations that force you to trade off one annoyance against another.

There remains a non-technical limitation: I have assumed that contributors are comfortable enough with version control to use a history-editing workflow effectively. I've lost all perspective on how hard this is for a newbie to learn; I expect (or hope?) jj makes it much easier than git rebase.

[syndicated profile] maru_feed

Posted by mugumogu

みりのお誕生日会、まるさんが元気になったらみんなで一緒にお祝いしようと 用意だけはしてありました。でもどうしようか悩んでいたところ、 もしかしたらまるさん、この辺でまだうろちょろしているかも、 そしてもしかしたら一緒に参 […]
[syndicated profile] ao3_news_feed

Over the past month, we rolled out behind-the-scenes upgrades and quality-of-life improvements across the site, including the addition of username links and chapter numbers to kudos and comment emails, respectively. We also made some major privacy and security enhancements, such as removing the email, birthday, and location fields from profiles and checking new passwords against known data breaches.

Special thanks and welcome to first-time contributors anna, Liz Watkins, Riya K, and theamandawang!

Credits

  • Coders: Abhinav Gupta, anna, Amy Lee, Bilka, Brian Austin, Ceithir, Connie Feng, Domenic Denicola, EchoEkhi, Hamham6, kitbur, Liz Watkins, marcus8448, Riya K, sarken, Scott, slavalamp, talvalin, theamandawang, weeklies
  • Code reviewers: Bilka, Brian Austin, Ceithir, HamHam6, james_, lydia-theda, marcus8448, redsummernight, sarken, Scott, weeklies
  • Testers: Allonautilus, ana, Anh P, Aster, Bilka, Brian Austin, calamario, choux, Dre, Keladry, Lute, lydia-theda, Pent, redsummernight, Runt, Sanity, sarken, Teyris, therealmorticia, weeklies, wichard

Details

0.9.420

On July 15, we massively improved the user search used by admins.

  • [AO3-6565] - We've improved the user search feature available to admins by moving it to Elasticsearch and adding the ability to search by past email addresses and usernames.
  • [AO3-7042] - Instead of redirecting to the main Collections page, we now give a 404 error if you try to access the collections page for a nonexistent user, work, or collection.
  • [AO3-7004] - We've added a database index to make it faster for database admins to search for comments using a specific guest name.

0.9.421

Following some email-related changes in our July 24 deploy, embedded images are now always stripped from comment emails, and usernames in kudos emails now link to the users' dashboards.

  • [AO3-3154] - When you receive a kudos notification email, the names of users who have left kudos now link to the users' dashboards.
  • [AO3-6060] - Even though they no longer had access to tag comment pages, former tag wranglers would still receive email and inbox notifications of replies to their old tag comments. This was both annoying and confusing, so we've stopped it from happening.
  • [AO3-6746] - If you changed your username or pseud name and you had some chapters that you co-created with another user, the chapter bylines would not always get updated with your new name. We've changed this so the cache is refreshed more reliably.
  • [AO3-6929] - The list of gift exchange sign-ups visible to collection maintainers now includes the pseud and username of signed-up users, instead of just their pseud.
  • [AO3-7011] - Using the Tab key to navigate in desktop Safari used to select hidden inputs, causing the focus indicator to temporarily disappear. We've fixed it so only visible links and inputs receive focus.
  • [AO3-7032] - If you tried to add your email to the invitation queue when it was already part of the queue, you would see two copies of the same error message. Now it only shows the error once.
  • [AO3-7065] - We fixed some intermittent failures in the automated tests for the bookmark importing tool used by Open Doors.
  • [AO3-7052] - We did a schema dump to capture what the current data structure looks like before we upgrade to Rails 7.2.
  • [AO3-7053], [AO3-7054], [AO3-7067], [AO3-7068] - We updated a whole bunch of gems and GitHub actions: reviewdog/action-rubocop, awalsh128/cache-apt-pkgs-action, nokogiri, and thor.
  • [AO3-5352] - We prepared the preface of work downloads that are attached to work deletion emails for translation.
  • [AO3-7001] - As an anti-abuse measure, we now strip embedded images from comment notification emails even when image embeds are enabled on the site itself.

0.9.422 & 0.9.423

On July 28, we made a number of small improvements all around the site. There were some issues while deploying these changes, so we did another release to fix it all up on the same day.

  • [AO3-5609] - We stopped sending subscription notifications for works hidden by admins, since hidden works are inaccessible to other users.
  • [AO3-7006] - When a comment contains an HTML list, the list numbers or bullet points no longer overlap with the commenter's icon.
  • [AO3-7024] - You'll no longer get an incorrect success message if you mark items in your inbox as read without selecting any comments.
  • [AO3-5476] - We cleaned up some unused code in the works controller.
  • [AO3-7064] - We updated the gems we use for automated testing.
  • [AO3-7072] - We updated the unicode gem to solve some issues with developing the AO3 software on Macs with Apple Silicon chips.
  • [AO3-5346] - Collection maintainers get an email notification when matches in a gift exchange have finished generating. We've improved the text of this email and prepared it for translation.
  • [AO3-6484] - We made a small change to the code that generates the HTML class names we use for hiding work blurbs by muted users. We were hoping this tweak would improve performance, but unfortunately it had no effect, so we'll have to try again.
  • [AO3-6997] - If an Open Doors archivist tries to leave kudos while logged in to an archivist account, they'll get an error message telling them to log in with their personal account instead.
  • [AO3-7015] - Work blurbs now contain an invisible code comment with the work's update date, to make it easier for developers of third-party tools to automate downloads from index pages like tags, bookmarks, and search result listings.
  • [AO3-7021] - To make it easier to filter or search using work languages, we've added the language codes on the Languages page.
  • [AO3-7057] - We now provide any applicable error messages when an admin attempts to send an invitation directly to an email and something goes wrong.

0.9.424

On August 5, we deployed another batch of miscellaneous fixes.

  • [AO3-5025] - The Tag Wrangling committee can now use the Rich Text editor to edit the Wrangling Guidelines pages.
  • [AO3-7076] - We fixed some unwanted shadows that Chrome was adding to radio buttons and checkboxes.
  • [AO3-7088] - We fixed some flaky automated tests related to importing works from LiveJournal.
  • [AO3-7074] - We removed some unused CSS from our default site skin.
  • [AO3-6580] - We updated the account creation confirmation page's title from "Create Registration" to "Account Created" so that it's clearer you've successfully made an account.
  • [AO3-6818] - When an admin bans an email from being used for guest comments, that email is now also banned from requesting invitations.
  • [AO3-7026] - When we run a spam check on edited comments by new users, we now tell the spam checker that it's an edit.
  • [AO3-7046] - We migrated the subscriptions table so it can hold more rows and we won't run out of room in the future.

0.9.425

On August 19, we deployed an important change to account security that checks new AO3 passwords to see if they've been part of a known data breach. We also began allowing CSS variables in site skins.

  • [AO3-7073] - To better protect users' privacy, we've removed the preferences and fields to display emails, birthdays, and locations on user profiles.
  • [AO3-7091] - We stopped using fixtures in our integration tests.
  • [AO3-7098] - We updated cache-apt-pkgs-action again.
  • [AO3-7099] - We bumped the version of actions/checkout – a utility that helps run automated tests on our code – from version 4 to version 5.
  • [AO3-3071] - Comment emails now include the chapter number, so you don't have to follow the comment link to know where exactly it was left.
  • [AO3-7087] - To improve account security, we updated our password change process to prevent users from choosing passwords that are known to be compromised on other sites. (If you missed our post back on World Password Day, we also have some tips for keeping your AO3 account secure!)
  • [AO3-7090] - We changed links in emails to be HTTPS instead of HTTP.
  • [AO3-7093] - We added an automated test to make sure the fixtures used for seeding development databases result in valid records.
  • [AO3-7094] - We now allow limited use of CSS custom properties in site skins! You can find more information in the skins help text.

0.9.426

We upgraded to Rails 7.2 on August 26.

  • [AO3-7058] - We updated our version of Rails from 7.1 to 7.2.
  • [AO3-7095] - We added more example admin and user accounts with a greater variety of roles to our basic development dataset, which will make it easier for coders to work on things that require specific access levels.

Interesting app for Android [tech]

Sep. 10th, 2025 05:14 pm
siderea: (Default)
[personal profile] siderea
I don't know who needs to know about this, but:

I just discovered the Android app "Periodically". It's described as an "event logger". It's for keeping track of when a recurring thing has happened, and figuring out what the average time is between occurrences. You just keep it updated each time the event happens, and it will do the math for you to figure out the frequency, and even give you a notification when it predicts the event is likely to happen again. If you're tracking more than one thing, it will try to suss out correlations for you.

I mention because twenty five years ago or so, I needed exactly this functionality and could not find any application that would do what I needed, so I wrote a thing for myself, and since then a lot of people I've mentioned it to have wondered where they can get one like it. Mine was Mac/Palm Pilot, so not of much use to most people, especially these days.
Lo, somebody seems to have realized the need for this functionality, and brought it to the market. So I thought I'd mention.

Now, in this day and age, a lot of people, especially in the US, are concerned with security. Especially if they're tracking something to do with their health. This app is not specific to health, so nothing about it immediately reveals that it is storing health information on casual inspection; you could use some sort of other term for whatever health condition it is you are actually tracking. So, for instance, If you were tracking how often your migraines happened, you could call that "new box of cereal".

This app defaults to local-only data storage on your Android device, and the developer claims that it only collects "app activity" for analytics, and shares nothing with third parties. It outputs CSV and has an option to back up to Google Drive.

I haven't tried it myself, but it has a rating of 4.6 stars out of five on the Play Store.

Reviewers on the Play Store note that tracker apps that are specific to the kind of event – such as health- specific loggers – often have needless complexity, and often some weird ideas about graphic design. They praise this app for its clean, elegant look and simple, effective functionality.

In addition to its obvious applicability to episodic health conditions, it strikes me as potentially extremely useful in one of the trickier parts of prepping: figuring out one's burn rate of resources. I think I might trial it to help me figure out how often I should expect to have to buy a fresh bale of toilet paper and how long the big bottle of ibuprofen will last me.

What I'm Doing Wednesday

Sep. 10th, 2025 02:05 pm
sage: A crocheted Spock doll made by Sage (yarning)
[personal profile] sage
books
The Disorderly Knights (The Lymond Chronicles #3) by Dorothy Dunnett. 1966. cw: yet more animal harm and graphic violence, child harm, violence against women, dubcon, mention of sexual assault. Swashbuckling! Explosions! Sieges! Mercenaries! Car chases! Malta, Tripoli, Scotland, etc. Much more accessible than the first one, which was Dunnett's first novel. Weird pacing at the end, though.

currently reading: Pawn in Frankincense (The Lymond Chronicles #4) by Dorothy Dunnett. 1969. Baden, Algiers, so far. Piracy!

yarning )

gift rec request
Mom's having trouble finding a good birthday gift for Niece. She requested "binoculars or a telescope," which another family member is taking care of. Point being, she's not your average almost 5-year-old. She's on swim team, is in ballet, and missed the cut off for kindergarten, so she's still in preschool. I went looking for gift ideas, but they all have small parts, and her brother is still only two and might get into her toys and try to eat things he shouldn't. So no LiteBrite sets or such yet. Any gift ideas, preferably educational, would be much appreciated!

dirt
another baby monstera delicosa has come up! I am so happily surprised! I managed to water nearly everything yesterday & all the other plants are doing well, minus the few who still have a thrips situation, grrrr! :smites all thrips:

healthcrap
had a difficult day Monday, but managed to go get my monthly allergy shot. It's irritating that socializing for less than 2 hours on Sunday makes Monday obligations so challenging. Then I overdid it yesterday and barely slept last night, so today isn't great either. /disability. cut for discussion of intended weight loss )

media
I started watching S5 of Lower Decks, and it's so good! I'd forgotten how much I loved S4.

augh
The trunk release lever of my car stopped working. Pretty sure, based on googling, that the cable broke, though I haven't gone spelunking to check. I can still open the trunk with a key, at least, but it's one more thing I need to take care of...or to ignore indefinitely. :(

yuletide!
noms open in less than a week, on the 15th, yay! And the mods have upped the number of fandoms you can nom (5) and request (8)!

#resist
10/18/25: No Kings Day #2

I hope all of y'all are doing well!

2025 RPF Coordination Post

Sep. 10th, 2025 11:37 am
yuletidemods: A hippo lounges with laptop in hand, peering at the screen through a pair of pince-nez and smiling. A text bubble with a heart emerges from the screen. The hippo dangles a computer mouse from one toe. By Oro. (Default)
[personal profile] yuletidemods posting in [community profile] yuletide_admin
Please use this post to talk about the RPF or RPF-adjacent fandoms you're interested in nominating, requesting, or offering this year!


RPF nomination categories can be fluid in Yuletide, so we encourage RPF fans to coordinate with each other about the social circles, career groups, and characters you're interested in, to help ensure the resulting categories suit as many people as possible.

Coordinating your RPF nomination with other fans is the best way to make sure we can approve RPF fandoms quickly and easily. You are also welcome to reach out to us directly at yuletideadmin@gmail.com to discuss a potentially sensitive nomination.
This year's eligibility post covers what characters and fandom labels you can nominate. Here is a post from 2023 that explains why we may reject some RPF nominations.

While each RPF fandom must still meet Yuletide rules for size (no more than 1,000 complete works in English), we won’t reject an RPF fandom label for being too broad (i.e., for covering too wide a topic). However, we prefer not to approve two fandoms if one of them is a subset of the other, so please use this post to make sure your nomination doesn't clash with someone else's.

Click for links to some previous tagsets
2024, 2023, 2022, 2021, 2020, 2020, 2019, 2018, 2017, 2016, 2015, 2014.


Schedule, Rules, & Collection [still being tweaked for this year] | Contact Mods | Tag Set | Community DW | Community LJ | Discord | Pinch hits on Dreamwidth

Please either sign in to comment, or include a name with your anonymous comments, including replies to others' comments. Unsigned comments will stay screened.

#72: Chicken Soup

Sep. 10th, 2025 05:36 pm
mekare: Flower patterned Japanese paper (Default)
[personal profile] mekare posting in [community profile] drawesome
Title: Chicken Soup
Artist: [personal profile] mekare
Rating: G
Fandom: -
Content Notes: watercolour

Clicky preview:

james_davis_nicoll: (Default)
[personal profile] james_davis_nicoll


Otaku Hina is delighted that her Japanese neighbour Kyuta looks just like Hina's favourite anime character. Alas, Kyuta dislikes anime almost as much as vampires like Hina.

Otaku Vampire's Love Bite, volume 1 By Julietta Suzuki (Translated by Tomo Kimura)

No hike today

Sep. 10th, 2025 01:33 pm
the_shoshanna: my boy kitty (Default)
[personal profile] the_shoshanna
The forecast for our last day of hiking was for thundershowers all day, so we said not today, Satan, and rode along with our luggage to our final stop on this part of our trip: Hay-on-Wye. We arrived a little after 10, walked around a bit (often in light rain), changed some euros we've had kicking around for six years, poked our noses into some of the many bookshops the town is famous for, and have now collapsed in our B&B; Geoff is snoring next to me, and even I, who virtually never nap, can hardly keep my eyes open. Taking the day off was a good call.

Profile

jeshyr: Blessed are the broken. Harry Potter. (Default)
Ricky Buchanan