_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Improved Git Diffs with Delta, Fzf and a Little Shell Scripting
good-idea wrote 4 hours 40 min ago:
Related and a step beyond just viewing diffs - has anyone found a good
TUI solution for a local equivalent of doing GitHub PR reviews?
I love the simplicity of using existing tools in this post.
It would be nice to have something similar that would allow for adding
online comment threads on a diff, and output it to a simple markdown
file. Of course, I'm thinking about a local agent workflow here.
whinvik wrote 3 hours 34 min ago:
Haven't used it but have seen some online recommendations for
gh-dash.
URI [1]: https://github.com/dlvhdr/gh-dash
rs545837 wrote 8 hours 14 min ago:
We've been building an open source tool called sem ( [1] ) that takes
this one level further: entity-level diffs instead of AST-level.
Instead of showing you which syntax nodes changed, it shows you which
functions, classes, and methods changed, classifies the change
(text-only, syntax, functional), and walks a dependency graph to tell
you the blast radius.
The delta + difftastic integration problem in that issue is interesting
because sem already has the pieces both sides need, before/after
content with full context for every changed entity, plus structured
JSON output. The blocker in #535 is that difftastic's JSON doesn't
include surrounding context. sem's output includes complete entity
bodies by default.
Would love to collaborate on a common interchange format if anyone from
the delta or difftastic projects is interested. Entity-level
granularity sits naturally above AST-level diffs and below file-level
diffs, and having a standard way to represent "what changed and what
depends on it" would be useful for the whole ecosystem.
URI [1]: https://github.com/ataraxy-labs/sem
dominotw wrote 7 hours 42 min ago:
can diffs be piped through an llm to give you something higher level
but still tie it back to to changes
rs545837 wrote 7 hours 8 min ago:
You can, but it's slow, expensive, and hallucinates. An LLM looking
at a raw diff might miss a renamed function or invent a dependency
that doesn't exist. sem does it structurally: parses both sides
with tree-sitter, computes structural hashes, walks the real
dependency graph. If you want to layer an LLM on top for
summarization, you're feeding it 10 entities instead of 500 lines
of unified diff.
esafak wrote 7 hours 46 min ago:
It tells you the function changed but not how; you still need
line-level diffs.
rs545837 wrote 7 hours 10 min ago:
Right, sem gives you both. sem diff --verbose shows the full
before/after body of each changed entity. The entity-level view
tells you what changed and what's affected. The line-level detail
is still there when you need it.
jeninho wrote 9 hours 20 min ago:
Been using delta for a while now, the side by side mode alone was worth
the switch. Pair it with fzf and you can browse commits interactively
which is a lifesaver on repos with messy history.
diath wrote 9 hours 21 min ago:
I had to give up on diff-so-fancy because it would break a lot when
used with `git diff --patch` but this post just reminded me of the
issue and it turns out that it has recently been fixed, so I may give
it another go.
URI [1]: https://github.com/so-fancy/diff-so-fancy/issues/498
baumy wrote 10 hours 35 min ago:
As someone who's used vim + a shell as my IDE since the start of my
time using computers, it's been really awesome (and occasional eye-roll
inducing...) watching people discover all these tools now that claude
code is sending them into the terminal.
A lot of posts like this are making it to the front page of HN now that
new people are exploring this world for the first time. That's great,
the more the merrier, but gets a bit frustrating when a post title is
written as if it's discovered some new awesome development tool or
methodology, and it's just something people have been doing for years
or even decades. This post isn't that big of an offender, but I'm
thinking more of stuff like this [0] that it reminded me of.
I should try to be less grumpy about it, but I hope people also try to
recognize how often these "new" tools they've been discovering have
been routinely used long before LLMs. Maybe I'm just hitting my
get-off-my-lawn stage, but it's a bit jarring to come to hacker news
and see upvoted posts that are just "look, I can color the diffs in my
terminal!". I'm glad this person discovered it, but I thought that was
table stakes for the community here.
[0]
URI [1]: https://x.com/dani_avila7/article/2023151176758268349
godelski wrote 4 hours 1 min ago:
I'm a long time vim user and terminally terminal as well. I also feel
very mixed
On one hand I'm really glad more people are coming over. There's been
an explosion in TUIs and it's helping that people understand how
important UX and visual design is.
On the order hand I'm annoyed as things move from unix philosophy and
it feels like people are just trying to make terminals GUIs. The
beauty of the CLI is its power. I'll give up the UI because it is so
powerful. The learning curve is steeper but it's not that bad once
you get used to it. And since so many people go through the same
experience there's a shared language across many different tools.
Maybe an obvious example of that is how people conflate "vim mode"
with using hjkl for movement. Even `set -o vi` in bash is more rich
of an experience than what many people think "vim mode" should mean,
at least to a vim user. But lots of that shared unix language is
getting lost and I'm not a fan of those tools
nickjj wrote 6 hours 58 min ago:
> watching people discover all these tools now that claude code is
sending them into the terminal.
Hi, I'm the author of the post.
I don't like replying to comments like this but I think it's
important because of how "invasive" LLMs have become and how they
might jade your opinion (not you specifically, but everyone) on any
type of output such as blog posts, videos, code, etc..
I wrote about this because I've done contract work for lots of
companies, spoken with lots of developers and every time they see the
output of Delta they are like "how did you make your git diffs look
so cool?", so I thought it was worth sharing because there's lots of
folks out there who might not know about it.
By the way, this concept of having a terminal based workflow is
something I've openly been using, sharing and writing about for
around a decade. There's 500+ posts and videos on my site covering a
ton of different topics.
You're more than welcome to explore any of the 70+ open source
projects I maintain [1] , with git histories going back well before
LLMs existed. Thousands upon thousands of human written lines of
shell scripts, Python scripts, Docker set ups, etc.. Every readme
file was written by hand and 99.999% of current day code is by hand
too. I've been playing with AI to learn new languages like Lua to
solve specific problems but I end up rewriting most of that code
afterwards. You can view comments I've made on HN in the past in how
I feel about LLM code haha.
URI [1]: https://github.com/nickjj?tab=repositories
MeetingsBrowser wrote 10 hours 24 min ago:
Having used both terminal and GUI based development environments, the
good GUI environments blow terminal based workflows out of the water.
There are pros and cons to each. Vim can do some neat things, but GUI
based IDEs are generally useful and easier to use out of the box for
development.
The terminal tools are getting popular because people donât need to
do development. Claude is doing the development task. People just
need to quickly review code in terminal.
baumy wrote 9 hours 14 min ago:
I completely disagree. Terminal workflows are superior in a number
of ways. Most important to me are that they are more composable and
more customizable. The learning curve is tougher, but the "skill
ceiling" on them is higher. The ease and speed with which somebody
comfortable in their terminal based environment will navigate
through the tasks they need to do will always exceed what is even
possible in a GUI.
I would say that GUIs are superior for a few specific use cases,
but otherwise sub par. Step through debugging comes to mind as a
good GUI use case, but even that I'm not sure if it's because a GUI
is inherently better, or making a terminal based debugger is harder
and so nobody has made a good one yet.
hrmtst93837 wrote 4 hours 41 min ago:
Composability sounds great until you need to onboard three new
devs who would rather gouge their eyes out than decipher an
80-line shell script that breaks on macOS because one env var or
BSD tool behaves differently.
That cost is not theory.
Terminal skill ceiling exists, but a lot of custom flows are just
local maxima that look elegant to the person who wrote them and
miserable to everyone else who has to debug or extend them.
GUIs give up some raw power, yet for diff review, history
browsing, and getting a team moving without turning every
workflow into a tiny priesthood, they are often the better tool.
MeetingsBrowser wrote 8 hours 57 min ago:
> Terminal workflows are superior in a number of ways
What specific ways do you find boost your productivity the most?
For me, the things terminal workflows can do faster take up
almost a negligible amount of my workday.
Curious to hear if Iâm missing out on a terminal workflow, or
if my workday is just very different from yours
backscratches wrote 9 hours 22 min ago:
Lol terminal is better for everything except maybe the one case you
mentioned: first time use feature discovery, and that's debatable
MeetingsBrowser wrote 9 hours 9 min ago:
I spend half or more of my time debugging and I think I would
quit if I were forced to only use terminal based tools.
rileymat2 wrote 9 hours 16 min ago:
That seems a little harsh. GUI tools can give us a more vibrant
and useful interface.
But, I think the main problem is that although there have been
many attempts we have not gotten to a standard way to compose
different GUI tools easily or repeat actions.
rileymat2 wrote 9 hours 29 min ago:
> but GUI based IDEs are generally useful and easier to use out of
the box for development.
This is true, they are much better for discovery and affordance,
but as you progress with your tooling and tool usage there is a
much higher ceiling on your productivity with other tools and their
composability. In my opinion, not putting effort into learning
tools ultimately holds a lot of people back from their potential.
MeetingsBrowser wrote 9 hours 0 min ago:
I use both and mostly agree, but for me I donât think the ROI
for learning terminal based tooling is there.
They make some parts of text manipulation faster, but those parts
of text manipulation take up less than 1% of my time spent
working.
Things like debugging, which take up a large portion of my time,
are not so nice in terminal based environments
packetlost wrote 7 hours 23 min ago:
I work 99% in a terminal and fire up a JetBrains IDE when I
need to do deep debugging. Itâs so rare for me though that
itâs worth more for me to get good at the terminal stuff.
Iâm sure this depends heavily on the type of work being done,
game dev for example really needs a good debugger. That being
said, gdb and others have perfectly fine text mode interfaces,
albeit with a steeper learning curve.
As always, the âbestâ tool is the one your most familiar
with that gets the job done. Text vs GUI doesnât really
matter at the middle of the bell curve.
rileymat2 wrote 7 hours 48 min ago:
Yes, for things like Node, I do use tools like the chrome dev
tools for debugging and such.
But find a terminal first approach leads me to other tools like
curl and jq usage as I go. I see coworkers using a ton of time
trying to repetitively execute the code to see those spots in
really inefficient ways. And end up completely lost when they
could be using tools like git bisect.
Or another good example devops type support is if one web
server out of many seems to be misbehaving, I can use aws
command line to get internal ips behind the lb to curl to grep
and find it in minutes after others have tried for hours. It
makes it second nature if your mind goes there first.
ab71e5 wrote 9 hours 44 min ago:
Why would you say GUI based workflows are better (ignoring LLMs for
now)? I would maybe give you debugging with breakpoints but for
anything else I love my neovim with tmux setup
MeetingsBrowser wrote 9 hours 4 min ago:
I spend more time reading and debugging code than writing it.
Vim and other terminal tools make doing complex text manipulation
easy, but I rarely need to do anything complex when writing code.
I also work from different machines and ephemeral vms regularly
and donât want to spend time setting things up each time.
I can install vscode and the one lsp plugin I need in under a
minute. In contrast, Vim doesnât even have line number enabled
by default.
WhyNotHugo wrote 7 hours 42 min ago:
I find that (neo)vim enable code navigation to be much faster
than any GUI as well, once past the learning curve. If youâre
going to work with code long term (eg: years), the learning
curve pays off quickly.
henrebotha wrote 8 hours 57 min ago:
I don't think setup time is a fair comparison here. Any dev who
cares to use CLI tools has a dotfiles repo that sets up
everything in "under a minute".
MeetingsBrowser wrote 8 hours 48 min ago:
What about installing the tooling needed to make various
plugins work (ripgrep, fd, lsps, etc)?
And I work on different types of systems, which have
different requirements and different ways of installing these
tools.
Yes, there are other tools to help automate this process as
well, but vscode âjust worksâ
henrebotha wrote 6 hours 29 min ago:
I mean yeah, there are tools to automate it. I think you
may have a point if both of the following hold true:
1. You very frequently have to install your setup from
scratch.
2. Preconfiguring something that aids in installing from
scratch is not viable or sensible. (Perhaps you work in an
environment where you're not allowed access to your
personal dotfiles repo, for example.)
But I think most people will fail at least one of these
checks.
linsomniac wrote 11 hours 14 min ago:
I had been using delta for around a year and liked it, but still found
some of the diffs I was looking a bit hard to read. A few weeks ago
after a discussion on HN I tried difftastic, and have become a fan.
You might want to consider it if you go down this rabbit hole.
URI [1]: https://difftastic.wilfred.me.uk/
TacticalCoder wrote 2 hours 9 min ago:
> [1] ah, it's using tree-sitter to not bother reporting changes that
have no effect.
That's very nice!
Now, of course, the biggest issue is that our DVCes still are from
the paleolitic era and store source code as non-structured text files
instead of trees, so we need to the proper thing "outside" the DVCS
(which is using tools like diffstatic / tree-sitter: tools that have
seen the light).
It's basically the old "tabs vs space" and "tabs = how many spaces?"
and "bracket on the same line or not" discussions all over again. I'm
pretty sure I've got comment from 15 years ago saying that in a
proper world this shouldn't even be a concern because this should
purely be a client-side concern, on the dev's machine. And that the
DVCS should have a specific representation, not opened for discussion
(a code formatter for example, but ideally just the source code
already as a tree). And then no more bitchin' about tabs vs space,
about how many spaces is a tab worth, on which line brackets should
go, etc.
Don't get me wrong: it's great that people are doing the right thing.
But it's still a kludge that's needed because the underlying tool
were made by us and for us cavemen and really could have been oh so
much better.
URI [1]: https://difftastic.wilfred.me.uk/
nchmy wrote 4 hours 42 min ago:
Came to say this as well. Started with delta, then found difftastic.
Even better is using it via jjui, a fantastic TUI for jj vcs
nh2 wrote 8 hours 57 min ago:
Still waiting for Delta + Difftastic integration:
URI [1]: https://github.com/dandavison/delta/issues/535
TJTorola wrote 9 hours 19 min ago:
Came here to say this, difftastic is great as long as you are working
in a language where it understands the language tree (most
languages). Getting away from diffs being focused on line changes to
diffs that understand the actual language makes so much sense once
you start to use it.
DIR <- back to front page