On Fri, Nov 06, 2026 at 01:00:51PM +0100, Omar Polo wrote:
> Stefan Sperling <stsp@stsp.name> 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.

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?

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?

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.