51–60 of 79 posts
Earlier quoted context omitted.
Linear? That website makes my laptop heat up like nuts.
If also hijacks standard browser shortcuts: I try to open the file menu with alt-f, but instead it (un-) marks the issue as "Favorite".
Earlier quoted context omitted.
Not only is GitHub focused on AI, but they’re also making their UI slower and jankier by rewriting it in React. I feel like a “Linear for GitHub” is due.
Holy crap, is that why it's felt so syrupy recently? What was wrong with the old implementation?!
Ironically one of the reasons markdown (and other text based file formats) were popular because you could use regular find/grep to analyze it, and version control to manage it.
Definitely, but it's neat nonetheless because more and more things are "structured Markdown" these days. Extremely useful for AI reasoning and outputs.
We could have called it something like extended markdown language or something and use a wicked acronym like eXMaLa for it.
Shame no such technology exists and never did.
I wanted to point out little nitpicks for the documented shell invocations:
cat example.md | mdq '# usage'
mdq '# usage' echo "$ISSUE_TEXT" | mdq -q '- [x] I have searched for existing issues'
mdq -q '- [x] I have searched for existing issues' Thanks for sharing! No immediate use-case for me right now, but good to know something like this exists. I wanted to point out little nitpicks for the documented shell invocations: cat example.md | mdq '# usage' This can be changed into a stdin file redirect to avoid invoking an extra `cat` process (see Useless use of cat [1]): mdq '# usage' In a similar fashion, you can avoid an extra `echo` process here: echo "$ISS…
A cat written with UUOC might still be preferred for readability reasons, as reading a piped stream left-to-right might be easier to conceptualize.[14] Also, one wrong use of the redirection symbol > instead of > GitHub PRs are Markdown documents, and some organizations have specific templates with checklists for all reviewers to complete. Enforcing these often requires ugly regexes that are a pain to write and worse to debug This is because GitHub is not building the features we need, instead they are putting their energy towards the AI land grab. Bitbucket, by contrast, has a feature where you can block PRs using a checkb…
> Bitbucket, by contrast, has a feature where you can block PRs using a checkbox list outside of the description box I'm not sure this is better. I like the idea of the full context of the PR being available in a small set of relatively standardised fields. Smaller, non-semantic sets are easier to standardise.
It has saved us from self induced pain and is a great coordination point
> GitHub PRs are Markdown documents, and some organizations have specific templates with checklists for all reviewers to complete. Enforcing these often requires ugly regexes that are a pain to write and worse to debug This is because GitHub is not building the features we need, instead they are putting their energy towards the AI land grab. Bitbucket, by contrast, has a feature where you can block PRs using a checkb…
> This is because GitHub is not building the features we need, instead they are putting their energy towards the AI land grab. You throw the ball to where it's going. Gitlab might be delivering more value in the short term, but if things wind up looking significantly different in ten years, they might be in for a world of hurt. Innovator's dilemma is real. It's a danger to ignore the tectonic changes happening. It's…
So do the plagiarism machines!
Earlier quoted context omitted.
GitHub was ignoring users needs long before the AI craze.
It's hard to remember, but as soon as gitlab showed up, GitHub went from a "maybe someday if I make it" site to a "let's just use GitHub for everything" site. Prior to gitlab ratcheting up the usability, features, and cost effectiveness, I preferred hosted git for 99% of use cases.