On 08/30, van den Berg, Kasper wrote:
> Hello,
>
> `git range-diff <range1> <range2>` prints "segmentation fault" to
> the console and nothing else. It happens in git version
> 2.23.0.windows.1 and only occurs for some branches in my repository.
> I have not exactly determined when it does happen and when it does
> not (I'm not familiar with git's codebase). These are my results:
Thanks for your bug report.
I guess this is probably related to my patch series aiming at giving
nicer output in 'git range-diff', which probably introduced some bug.
> Status Version Config Result
> ✘ 2.23.0.windows.1 64-bit, local Segmentation fault
> ✘ 2.23.0.windows.1 64-bit, local, different ranges related to my current work Segmentation fault
> ✔ 2.23.0.windows.1 64-bit, local, different ranges completely different from my current work Expected range-diff output
> ✘ 2.23.0.windows.1 Remote connection to same workdir Segmentation fault
> ✔ 2.23.0.windows.1 64-bit, local, fresh clone, different ranges completely different from my current work Expected range-diff output
> ✘ 2.23.0.windows.1 32-bit, local Segmentation fault
> ✔ 2.21.0.windows.1 64-bit, local Expected range-diff output
> ✔ 2.21.0.windows.1 64-bit, remoteconnection to same workdir Expected range-diff output
>
> Both <range1> and <range2> comprise between 213 and 270 commits; git
> gc counts 140394 objects (Total 140394 (delta 110638), reused 137275
> (delta 107799)). I have not preserved the offending branch names.
> However, they contain 2 or more slashes and perhaps an at-sign
> (e.g. 'feature/'<featurename>,
> 'tmp/old@{'<i>'}/feature/'<featurename>, 'develop', and
> 'tmp/project-base').
I don't think branch names would cause this, but rather some diff that
range-diff doesn't handle correctly. Would you be able to gather a
backtrace from the segfault (not sure how to do this on Windows), or
share the repository where this segmentation fault occurs?
> To avoid the problem I returned to using git version 2.21.0.windows.1
>
> I there something I should take into account when doing `git
> range-diff` on a workdir or on a ranges of commits? What things
> should I look for? How can I repair the broken ranges? Why does
> version 2.21.0.windows.1 work while version 2.23.0.windows.1 does
> not?
I don't think there's anything you should do here, this sounds like a
bug in Git that should be fixed. It would be great if you could help
with some more details per above though, otherwise it's going to be
hard to track this down.
> With kind regards,
> Kasper van den Berg
