🐛 "capacity overflow" with git add -p

[rfwroo]

Hello! Following on from #320, I seem to still be experiencing the issue (or a very similar issue) in 0.18.2.

% delta --version                                                                                                                                                                                                                                                                                                                                                                                             
delta 0.18.2
% RUST_BACKTRACE=1 git add -p                                                                                                                                                                                                                                                                                                                                                                                  
thread 'main' panicked at library/alloc/src/raw_vec.rs:25:5:
capacity overflow
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: alloc::raw_vec::capacity_overflow
   3: alloc::str::<impl str>::repeat
   4: delta::paint::Painter::paint_lines
   5: delta::paint::Painter::paint_zero_line
   6: delta::handlers::hunk::<impl delta::delta::StateMachine>::handle_hunk_line
   7: delta::delta::delta
   8: delta::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: mismatched output from interactive.diffFilter
hint: Your filter must maintain a one-to-one correspondence
hint: between its input and output lines.

This seems to happen with any invocation of git add -p or git checkout -p, even with a trivial diff.
Update: this only affects git add -p and git checkout -p (and possibly other commands with -p flags) with certain diffs, see below.
With --no-pager the crash still occurs.

Please let me know if I can provide any more context.

[dandavison]

Hi @rfwroo. Hm. Can you give platform details, and git version? Does it really only occur with those two commands, not with git diff etc? Do they always fail, or is it dependent on the state of the repo? Are you able to give a repo and commit and diff at which this occurs? Possibly related to #1760

(And thanks for informing me of the existence of git checkout -p!)

[rfwroo]

Can you give platform details, and git version?

• git version 2.39.3 (Apple Git-146)
• MacOS 14.7

Does it really only occur with those two commands, not with git diff etc?

I've only observed it with the -p flag.

Are you able to give a repo and commit and diff at which this occurs?

This is consistent for me:

git clone https://git.netflux.io/rob/dotfiles
cd dotfiles
git checkout c39ec29b21751744a645b9bef5ba06d5fabee9bf
git checkout -p HEAD~3 # triggers the panic, note that HEAD~2 does not

[th1000s]

Do you have a syntax theme set? I am trying to figure out how repeat can be reached inside paint_lines, one possibility is that a certain theme dependent variable is set (internally config.zero_style.{foreground,background,is_reverse} inget_should_right_fill_background_color_and_fill_style() ). You call checkout -p directly inside a terminal, not inside a script which feeds y/n etc. answers to the prompt?

[rfwroo]

You call checkout -p directly inside a terminal, not inside a script which feeds y/n etc. answers to the prompt?

Yes, all directly from the terminal.

Do you have a syntax theme set?

Aha. Not exactly but I do have these long-forgotten lines in my config. Removing them seems to avoid the panic. 🎉

Not sure if that points towards a bug still or just some dodgy config?

[th1000s]

Yes, all directly from the terminal.

But also, no! git add -p hides the terminal from delta (I did not know that... ) which explains the first half of the mystery.

Not sure if that points towards a bug still or just some dodgy config?

No, the config should be fine, that is a very subtle bug. Zero lines are rarely styled (but, I already like it), so very few people hit this bug. You may have noticed that the zero-background always stopped column 80, unlike the plus/minus lines.

Thank you for the excellent reproducer, should be fixed in #1916. I am also working on an easier way to gather more details on what exactly lead to a crash in #1917.