151–160 of 184 posts
A third (fourth?) option worth mentioning here is difftastic[0], which uses "structural" diffing (as opposed to line diffing) for more granular diff highlighting. [0] https://github.com/Wilfred/difftastic
Meld works pretty well for these use cases. https://meldmerge.org/
A honorable mention is also https://kdiff3.sourceforge.net/ which has a lot of nice views.
Earlier quoted context omitted.
Git doesn't store diffs on logical level. Git operates on snapshots of trees. Commit is not "a collection of changes", it's a snapshot of a tree with attached predecessor of it. Then the another layer (which can be git, but also can be any other tool, adding custom diff tool to git is very easy) uses that to generate diffs. There is zero stopping anyone from adding contextual diffs to Git. Just ask it for content of…
Interesting. Wonder if something like that can be used to make git cleverer about merges for example.
Earlier quoted context omitted.
I also wonder if it's possible to go beyond this project and have git itself work on the syntax level instead of pure text.
Git doesn't store diffs on logical level. Git operates on snapshots of trees. Commit is not "a collection of changes", it's a snapshot of a tree with attached predecessor of it. Then the another layer (which can be git, but also can be any other tool, adding custom diff tool to git is very easy) uses that to generate diffs. There is zero stopping anyone from adding contextual diffs to Git. Just ask it for content of…
Linky: https://stackoverflow.com/questions/255202/how-do-i-view-git...
Earlier quoted context omitted.
Git doesn't store diffs on logical level. Git operates on snapshots of trees. Commit is not "a collection of changes", it's a snapshot of a tree with attached predecessor of it. Then the another layer (which can be git, but also can be any other tool, adding custom diff tool to git is very easy) uses that to generate diffs. There is zero stopping anyone from adding contextual diffs to Git. Just ask it for content of…
Interesting. Wonder if something like that can be used to make git cleverer about merges for example.
I was curious to see if anyone tried leveraging an LLM for summarizing diffs, and of course they have. An example here: https://github.com/anc95/ChatGPT-CodeReview/pull/21 It seems to me it misses the mark a little -- the text is so verbose, it's easier to read the code itself.
Maybe code reviews on the raw source code, does not need to be confusing anymore. Code reviews on the description of the source code is better.
I tried to prompt the LLM to just summarize the code, and i didn't like the result. The description is indeed verbose and somewhat inefficient.
I tried "write some comments about the source code, in the style of codinghorror" and the results were fantastic.
I am very interested, if someone has found some other styles that work just as well.
Edit: All this to say, that in the space of LLMs and source code, there is a start-up which will be a github disruptor, and a new era of code will begin.
I’m surprised how we’re all still using line based diffs and even seemingly stupid ones at that. But the tales I hear from across the pond of paid git alternatives which diff based on understanding the programming language seem to be pretty bad as well. Though for other reasons?
It might be because of formatting, but that is exactly what I would have expected them to handle well. Anyway, I have used a FOSS that does that, difftastic [1], and it does a pretty good job at language diff'ing without the annoyance of formatting as I hypothesised earlier. [1]: https://github.com/Wilfred/difftastic
If, for some odd reason, I wanted to compare two codebases that had diverged, and one had gotten some serious formatting changes (maybe the new person preferred a different coding style), I'd run them both through an automatic formatter program with the same options. For C code, "indent" is commonly available, for instance.
Earlier quoted context omitted.
It's still around, and still very useful for all kinds of comparisons when you need a UI https://www.scootersoftware.com/
It’s still around and has hardly changed one pixel since 2012! Yet it still feels fresh and there is no competing product that can challenge them. Most other diff tools lack good merge capabilities and are subpar in multitude of other ways.
Earlier quoted context omitted.
Automated tests aren't so much to make sure that the test you just wrote works. You are right that manual testing can do that better sometimes. Automated tests are so that the code you just implemented still works next months, when lots of other people have made unrelated changes, and weren't always aware of the interactions with other parts of the code. The automation is important, so that the tests get run, even wh…
To be clear, I'm not against automation. What we do for a living is write code, so when I say "automation is just more possibly buggy code", I'm not opposed writing more code (though I am opposed to overengineering). My point is that I don't place all of my faith in automated tests, and I'm not opposed to rolling up my sleeves, getting my hands dirty, and doing manual labor. Manual labor can be tedious, though, and t…
Apropos "automation is just more possibly buggy code" is also a good argument for static typing. Good static typing can express (some of) your business logic, so that (some) invalid states are forbidden by the types.
The result is that quite a few invariants that need to be checked via tests in eg Python can be expressed in the type system in eg Haskell. The type checker already exists and is implemented as fairly battle hardened code, so this way you reduce the amount of new, possibly buggy code.
An example: in Go the convention is that when a function can go wrong, it returns a tuple of two values and exactly one of them is supposed to be the null pointer. But the compiler doesn't help you enforce that convention at all, so you need testing (and perhaps careful reasoning).
By contrast, Rust's Result type enlists the compiler to make sure that you return exactly either an error or a business-as-usual value.
A third (fourth?) option worth mentioning here is difftastic[0], which uses "structural" diffing (as opposed to line diffing) for more granular diff highlighting. [0] https://github.com/Wilfred/difftastic
A fourth (fifth?) option worth mentioning is patdiff: https://opensource.janestreet.com/patdiff/ From what I remember, it sometimes (35%) made diffs easier to read, usually (60%) made no difference, and rarely (5%) made them harder to read. I used it a few years ago though, so I don't remember specifically what the problem was. The only reason I stopped using it was because I started using magit for git diffs.
I see that patdiff also provides word-level diffing. You could instead get that feature with `git diff --word-diff` or Delta (https://github.com/dandavison/delta).