Open RuRo opened 9 months ago
This looks like it might be a regression from #392
Hey! Piping the diff you provided produces correct output in current main
. You may want to try the same?
Okay, so this is a separate issue, but it seems that delta doesn't respect the GIT_CONFIG_GLOBAL
and GIT_CONFIG_NOSYSTEM
environment variables which is all kinds of wrong. So my "minimal" reproduction didn't work because delta was still reading my gitconfig.
After figuring that out, I was finally able to find the problematic option: file-style = omit
. You could argue that this is working as intended, however this behaviour doesn't really make sense. My understanding is that the main reason for the existence of file-style = omit
is to complement hunk-header-style = file line-number
, but since renames and copies don't produce hunks, then it doesn't make sense to completely omit this information.
So IMHO, file-style = omit
should only omit "empty" file section headers and keep the rename/copy information. Or at the very least there should be an option that does that.
Or alternatively, rename/copy operations should be represented by their own pseudo-hunks when file-style
is set to omit
.
it seems that delta doesn't respect the GIT_CONFIG_GLOBAL and GIT_CONFIG_NOSYSTEM environment variables
What delta version? I thought that this was a libgit2 issue that had been solved.
I patched the nixpkgs derivation of delta
to compile from dcae5bcc2428d1fb6f5ff7b9cddd7f268d9a3735 (main at the time of writing). Though delta --version
itself still reports the version as 0.16.5
.
P.S. looking at the build logs, I can see that libgit2-sys v0.15.2+1.6.4
was compiled/used by cargo.
P.P.S. looking at the upstream libgit2 repo, it seems that the relevant PR https://github.com/libgit2/libgit2/pull/6544 was first released in version 1.7.0.
Thanks @RuRo! I update git2 in main: https://github.com/dandavison/delta/pull/1647
Great. Circling back to the original issue, what do you think about the current behaviour of file-style = omit
+ hunk-header-style = file line-number
for renames/copies?
For diffs of binary files, I was thinking about keeping the line Binary files a/foo and b/bar differ
. Similarly standalone diff
can report Files foo and bar are identical
. Such line is not present for renames and copies of git diff
, but I think it may be useful to have it.
@dandavison what do you think about adding such line for otherwise empty diffs? It could be hidden behind an option like --show-status-line
that would be disabled by default, and perhaps enabled automatically along with file-style = omit
.
@RuRo would something like that work in your case?
@RuRo would something like that work in your case?
I think so. I guess, the specifics could use some bikeshedding, but I'd generally be okay with any solution that could show this information without showing the redundant (when used with hunk-header-style = file line-number
) file "section" headers.
Running this reproduction script:
Produces the following output: