From: "Omar Polo" Subject: Re: got diff vs file names with whitespaces To: Stefan Sperling Cc: gameoftrees@openbsd.org Date: Fri, 06 Nov 2026 15:51:29 +0100 Stefan Sperling wrote: > On Fri, Nov 06, 2026 at 01:00:51PM +0100, Omar Polo wrote: > > Stefan Sperling wrote: > > > On Thu, Nov 05, 2026 at 09:56:20PM +0100, Omar Polo wrote: > > > > @@ -252,8 +253,9 @@ output_unidiff_chunk(struct diff_output_info *outinfo, > > > > } > > > > > > > > if (print_header && !(state->header_printed)) { > > > > - rc = fprintf(dest, "--- %s\n", > > > > - diff_output_get_label_left(info)); > > > > + label = diff_output_get_label_left(info); > > > > + rc = fprintf(dest, "--- %s%s\n", label, > > > > + strchr(label, ' ') != NULL ? "\t" : ""); > > > > > > 'svn diff' always writes a tab here, no matter what the pathname contains. > > > I suspect we could do the same? > > > > done =) > > Hmm, I got a bit mixed up here because "label" refers to different > things between implementations. > > In 'svn diff' the label is something like "(working copy)" or > "(revision 123)", which is extra information following the path, > separated from the path by a tab. > > So the format used by 'svn diff' is: --- path\t(working copy)" > And because 'svn diff' always adds a label, it always prints a tab > after printing the path. diff(1) is the same, only it prints the date (mtime i think) of the file. > Now, 'got diff' never showed an extra label, only the path (which our diff > implementations calls "label" so this is where things get confusing). And > since we only print a path there was so far no reason to print a tab, right? nope :) > Is Larry patch trying to detect cases like "--- path (working copy)" (no \t) > and then tries to cleverly strip everything to leave just the "path" part? > Such that paths are truncated if they contain spaces without a trailing tab? bingo our patch doesn't care, and just splits on tab, which i think it's fine. git diff does what i was doing in my first diff, i.e. add the trailing tab only when the file name contains a space. i don't mind adding it always, especially after the pain of fixing all the regress :P > If that is the case I still think we should print the trailing tab since it > helps patch commands do the right thing with the path name. > > Or am I misunderstanding the problem? > > > what i was very close to forget is that we need to commit the diff part > > before in diff.git and then sync it, right? > > Ideally, yes. But we can also sync the other way around. if okay i'll do the commit on diff.git first, then sync and add the regress at the same time.