"but Claude is so good at resolving all these merge conflicts"

Fucking shudder

The fucking point of merge conflict resolution is
Uh

Fucking accountability for the changes.

Who is responsible for what

Deferring to the goddamn spicy auto correct

Ugh
Fucking hell

"it fixes it in five minutes rather than taking me 2 hours/days to review"

*Shudder*

The fuck

the development is a complete fucking mess with terrible source management if the merging process is taking days with regularity

Either way I'm
Not impressed with that practice. At all.

Like

What's the fucking point, where's the CI/CD

HOW is that level of merge conflict acceptable to begin with

@Loosf Ohgod...

@dragonarchitect like, having enormous, complex merge resolution issues is a symptom of an underlying issue with the fucking project management there.

Using a fucking llm to make the choices **for you** is putting a horrid bandaid over a deeper wound

@Loosf Is this work related or another project you're looking at?

@dragonarchitect no

this is complaining about something I just saw on bluesky and how a shitload of people are defending it and saying shit like "there is no honor in drudgery" and that yes it is good to automate

Automating is good! But like delegating shit that way is
uh
sloppy to say the least

@Loosf honestly (large, recurring) merge racconflicts should be way less racceptable than they are right now, especially with how hard it is to like resolve racconflicts longer than like 3 lines imo

also i was testing something out right now because i thought git couldn’t figure out author info of merge racconflict but ractually it merged the changed line into the wrong spot

@charlotte lol

@gimmechocolate @Loosf also VCSes should be patch theory based and not just looking at 3 files and then squinting between them to Guess what the changes were

@gimmechocolate @Loosf yeah i was musing about this in a rust chat a few days ago

and like we did have this a little bit. in lisp the code format is also its data format. You can manipulate both code and data in the same way!

and then we got unix which all but enshrined plain text as the One True Way of storing both raccode and data alike. And honestly to some extent it was better than the inherently tabular data of mainframes for examples, but i think it has held up software development innovation tbh

@gimmechocolate @Loosf this is also further solidified with the unix model of application design

a text file can be opened in a generic tool. If everything creates and racconsumes text files, the generic tool can be used (regardless of how poorly) with manipulation of it

However if the raccode was stored in some sort of binary AST format, suddenly you need your raccode editor to understand the language-specific format. Now you can’t use a generic “simple” editor or viewer for it anymore

But, as it turns out, i think people are generally okay with applications that are Not generic, or rely on language-specific editors or plugins anyways

@gimmechocolate @charlotte

I gotta say I fucking love how this set of posts of mine went into very different tangents about the underlying issues here and in bsky.

Seriously, this discussion about the underlying problems with **even** the fucking way the structures are, uh, structured was fascinating.

On bsky it was more about process design and engineering and issues about that and how the focus on Shipping Code are fuckin harmful.

I am so happy I get to read your perspective