Thanks, that makes sense. I actually just parsed aes as related to encryption without even considering how weird that was given the contect.
Yes, I will do that!
I wrote one for my own use (on Linux): https://github.com/mvz/mdv
What made you decide to squash when merging instead of leaving the commits in the history so you can always bisect?
I worked on a project that used haml, and merge conflicts in the haml files were very hard to resolve due to the lack of any nesting info besides indentation. I think it's worse than, e.g., typical yaml files because…
If you already know k8s, this is probably true. If you don't it's hard to know what bits you need, and need to learn about, to get something simple set up.
I can understand requiring 100% test coverage, but it seems to me that requiring a test file for every file is preventing your team from doing useful refactoring. What made your team decide on that rule? Could your team…
What makes you think TDD assumes that? It sounds like the complete opposite of what TDD is about.
For people who, like me, prefer to read the abstract first: https://www.arxiv.org/abs/2508.06471
In such cases, I generally checkout main, do the side quest, and rebase my original branch on top of it. Then, I can just continue without waiting for the side quest to be merged. Depending on the situation, I may make…
The idea is that --amend would be used before pushing the commit that it amends, and so before a reviewer ever sees the original commit.
Linking to the abstract instead would have been nice.
If you follow SemVer strictly, the version bump is not necessary unless the number of rerenders is part of the documented API.
What could the frameworks do to make it more natural for inexperienced developers to do the right thing?
This means having to keep these branches around cluttering up everything, and makes git bisect a lot more complicated.
The format itself has several warts, like the ancestor list continuation syntax, or whether or not to add a backslash if you want a literal asterisk. The implementation lacks checking, so for example if you have some…
Asciidoc starts out great but has a lot of surprising gotchas and complexities.
Wasn't that Perforce?
The result looks beautiful but there are too many surprising magical actions for my taste. E.g., I wonder how "Last year MIT handed out 104 degrees to wombats." would be rendered.
Git has a built-in GUI for that. Just run 'git gui'. It's not pretty but it works.
Thanks, that makes sense. I actually just parsed aes as related to encryption without even considering how weird that was given the contect.
Yes, I will do that!
I wrote one for my own use (on Linux): https://github.com/mvz/mdv
What made you decide to squash when merging instead of leaving the commits in the history so you can always bisect?
I worked on a project that used haml, and merge conflicts in the haml files were very hard to resolve due to the lack of any nesting info besides indentation. I think it's worse than, e.g., typical yaml files because…
If you already know k8s, this is probably true. If you don't it's hard to know what bits you need, and need to learn about, to get something simple set up.
I can understand requiring 100% test coverage, but it seems to me that requiring a test file for every file is preventing your team from doing useful refactoring. What made your team decide on that rule? Could your team…
What makes you think TDD assumes that? It sounds like the complete opposite of what TDD is about.
For people who, like me, prefer to read the abstract first: https://www.arxiv.org/abs/2508.06471
In such cases, I generally checkout main, do the side quest, and rebase my original branch on top of it. Then, I can just continue without waiting for the side quest to be merged. Depending on the situation, I may make…
The idea is that --amend would be used before pushing the commit that it amends, and so before a reviewer ever sees the original commit.
Linking to the abstract instead would have been nice.
If you follow SemVer strictly, the version bump is not necessary unless the number of rerenders is part of the documented API.
What could the frameworks do to make it more natural for inexperienced developers to do the right thing?
This means having to keep these branches around cluttering up everything, and makes git bisect a lot more complicated.
The format itself has several warts, like the ancestor list continuation syntax, or whether or not to add a backslash if you want a literal asterisk. The implementation lacks checking, so for example if you have some…
Asciidoc starts out great but has a lot of surprising gotchas and complexities.
Wasn't that Perforce?
The result looks beautiful but there are too many surprising magical actions for my taste. E.g., I wonder how "Last year MIT handed out 104 degrees to wombats." would be rendered.
Git has a built-in GUI for that. Just run 'git gui'. It's not pretty but it works.