Bit late to the party, but it looks like the author created a "framework" that allows for extremely rapid development of the simplest kind of CRUD app. Everything is fine and dandy as long as nothing needs to change, or if it needs to be changed, then the changer is the author themselves.

I applaud the author for their intellectual pursuit, but I don't think it's fair to compare this to codebases where one does not simply pass the POST request body into the database.

That's not necessarily the case, depending on how their pipeline was set up and what their VCS supports.

For example, you can always `git mv` the Java file to the Kotlin file and only then transform it, which keeps your history.

That keeps the history but not the annotations of the lines. Git blame will shows basically all lines as last changed by Kotlin transform.

This should be short enough to read: https://github.com/Artamus/git-split/

It's not a good implementation of ownership tags, unfortunately :(

Couldn't flutter work as public-first that then gets vendored into third_party? Or is that literally the fork strategy you are talking about that I'm too dense to understand?

Yeah, that's what I meant. Public-first is good in some ways, but it means some bugs might be discovered rather late.

What did it say?

Sorry for the less-than-useful reply, but I tried out most of the TEA TUI frameworks in OCaml and none of them worked very well or well updated.

I do not recall what problem I had with that particular one, but I ended up just using raw Notty in the end.

But that way you make stacked diffs/changes/PRs really hard, so is it really worth it?

I firmly believe GitHub makes reviewing individual commits in a PR so painful that I'd rather not do that.

I understand why the `use` syntax is preferable for its generalizability to many different "callback style" things, but the whole construct of `use foo <- result.try(bar())` is so much worse than defining let* in ocaml and being able to write `let* foo = bar() in`...

What would you say makes it much worse?

GitHub's quirks definitely make life much harder than it needs to be, but I've been using `git machete` for months now with great success in my team. The __one__ thing GitHub has that makes it all work is the fact that if you merge the parentmost branch, its immediate child will retarget its base branch.

I think if I had full "control" over my company's SCM workflows I would use a tool that considers a branch as a workspace and every commit in the branch becomes its own PR (personal preference, but in my experience it also motivates people to split changes more), but alas.