Hi, On Tue, 22 Jul 2025 at 03:56, Michael Paquier <mich...@paquier.xyz> wrote: > > On Mon, Jul 21, 2025 at 11:53:00AM +0300, Nazir Bilal Yavuz wrote: > > I realized that we actually don't trim the file, we do the opposite; > > read the file from both ends. Sorry for not realizing earlier. I will > > update the remaining patches according to that but I think trim_file() > > is helpful, too. What do you think about adding both > > I did not review the contents of the patch yet, as I was rather unsure > about the right semantics here. > > > ``` > > trim_file() -> trims $n lines from head or tail of the file and > > returns the remaining lines. > > read_file_ends() -> returns $n lines from head or tail of the file. > > ``` > > > > although trim_file() will not be used in these particular patches? > > And this made me wonder over the weekend if only showing the head > and/or tail of a file is always the best set of properties. > Then I came up that this could be something close to what git-grep > -A/-B is able to do. For example, for a crash, it would be much > cheaper to target a log entry that matches with what we see in the > usual crash stacks, then print the surroundings. The "trim" behavior > you have proposed is a subset of that, where the matching patterns are > the end and/or the beginning of the file to show. > > So the API could com down to a pattern matching, with "head" and > "tail" being the optional number of lines we'd want to print around > the pattern we are looking for.
That makes sense and could be really useful in more general cases but I think that discussion might be better suited for a separate thread. For this specific case, we are dealing with regression.diffs; which already contains the relevant diff output. We don't need to search for patterns here; we just want to include a small portion of the file in the error message, to spare users from having to open the file manually. -- Regards, Nazir Bilal Yavuz Microsoft
