Live data from Hacker News

Better Git diff output for Ruby, Python, Elixir, Go

tekin.co.uk

1–10 of 53 posts

Re: Better Git diff output for Ruby, Python, Elixir, Go

#6
post #2

Am I missing something? Those diffs look identical. Edit: got it. Thanks!

In the first diff after the @@ there's a reference to the enclosing class, in the second diff it's a reference to the enclosing method. Which could help perhaps if the methods are moved?

Re: Better Git diff output for Ruby, Python, Elixir, Go

#9
post #2

Am I missing something? Those diffs look identical. Edit: got it. Thanks!

The header that indicates context. Default: @@ -24,7 +24,7 @@ class TicketPdf Configured: @@ -24,7 +24,7 @@ def tickets_as_html

Ah, thanks. I scanned those so many times but I never caught it. I think I'm used to not reading the header because, as this points out, it isn't always useful.

Re: Better Git diff output for Ruby, Python, Elixir, Go

#10
I tried to figure out why the extensions aren't configured by default.

I found a 2011 patch/proposal to make it the default, which appears to have stranded: https://lore.kernel.org/git/20110825204047.GA9948@sigill.int...

With some discussion by the patch's author of possible downsides (https://lore.kernel.org/git/20110826025913.GC17625@sigill.in...):

> I think it could be a problem in the future if the builtin userdiff drivers started growing more invasive options, like automatically claiming to be non-binary (i.e., setting diff.cpp.binary = false by default). In other words, I think we have two options:

> 1. Builtin drivers like "cpp" can stay minimal, only setting funcname and color-words headers that aren't going to produce terrible results if we are wrong about detecting by extension.

> 2. We force the user to identify file types manually, so we can't be wrong. The "cpp" diff driver means "you are a text C file", and if a user mis-marks a binary file with that diff driver, they are the one who is wrong.

> So if it's an either/or situation, we should decide not only that extension auto-detection is a good feature, but that it trumps adding more advanced features to the builtin drivers in the future.

> Or we could decide that the extensions really are good enough, and if you really do have binary files named "foo.c", it's your problem to override the defaults with "*.c -diff".

There might be more recent discussion that I didn't find.

Post reply on HN