tawb

This is rad man! I've thought about this a lot when I was running my company. How do I link a ticket's completion to automations that update customers that new features or bug fixes are out?

I've always envisioned as a comment or plug-in on the ticketing system itself. Then when the branch linked to that ticket was completed and deployed, it'd trigger a marketing automation or something like your tweet (xeet?) mechanism.

Cool stuff! Sorry you're getting a couple of sarcastic comments here.

Thanks for the detailed reply! A bunch of interesting points, and many things for me to go dig into more.

I definitely agree with your points about UI and the ceremonies of our current version control system.

One thing I've been thinking about this morning is that maybe it isn't the underlying protocol that needs to evolve, but the user experience that sits on top of the protocol. As I've asked this question to many engineers in my network, most are satisfied with the technical performance of git and the problem it solves, and their pains are almost all on the UX and organizational layer.

That's helpful context, thanks!

That's a super interesting take. The obvious thing is that the surface area of automation has improved and you can build a lot of tools to help with that, but you also need tooling to help deal with that overload of new automation - especially if your bandwidth is limited.

Can you expand on that for me?

I know there are issues with open source projects getting a lot of spam PRs from folks trying to fluff their contributions on their profiles. I can definitely see that getting worse with AI systems, but I haven't been in these communities enough to be familiar with that pain myself.

My experience with git has been pretty limited to Github. I've been working on software for five years, and mostly full stack in small startup teams so I'm lacking some breadth of experience that I was hoping to find some more of on HN.

But a few things that have always stood out to me about the user experience of version control:

- Git allows us to work in parallel effectively on different branches, but when our whole team is focused on one set of interrelated new features, we spend a lot of overhead coordination time figuring out how to not create conflicts for eachother. So we can work in parallel, but not in real-time with eachother's changes. The multiplayer aspect of design in Figma comes to mind here.

- I and many folks at my level use github in much simpler way than many older coworkers do. I rarely touch anything that isn't basic branching, commits and merging

- As a very visual thinker, it took me a very long time to grok git and what I was doing. As I've worked with more devs who come from non-engineering backgrounds, I've found this pretty common