• 0 Posts
  • 12 Comments
Joined 7 months ago
cake
Cake day: September 15th, 2025

help-circle

  • This argument doesn’t really hold up, honestly. That is all easily done with shell scripting, and shell scripts can be committed to source control and shared to other members of the team easily. This is what my team does for our common API needs. It even has ecosystem support in many places, such as popular openapi renderers providing curl command examples for routes automatically, being able to copy the exact request made by a web browser as a curl command from the network tab automatically, and so on.

    I use curl for absolutely everything, including testing out my work for each and every ticket I work on. Been doing this for years now. It works great and has many, many advantages over property bullshit like Postman.








  • The default difftool is vimdiff, which is not a GUI program. But no, the point of difftool is to iterate through files to diff and pass the different versions to an external program. There are many external CLI and TUI diffing programs. The point, though, is that the git CLI is still the driver of everything and you still have the full range of options available to git diff, rather than some GUI program being the driver, which are universally limited in what they can do.

    Personally, I load regular git diff output into a vim buffer via :read. Unified diff is largely superior to side by side diffs, IMO, because most of the time, changes in one file are accompanied by changes in a number of other files, so it’s useful to be able to quickly follow a thread of changed calls or whatnot. And with unified diff output, you can see and manipulate hunks directly.