Richard Hipp <d...@...> writes:
:
> > When I create a patch file using
> > fossil diff > patch.txt
> >
> > the resulting file cannot be used for patching. It seems there is an
> > extra 0D line separator (0d 0d 0a) for the actual source lines. (---,
> > +++, <at> <at> lines are OK).
> >
> > The source files have normal Windows line endings, 0d 0a.
> I saw the same annoyance in fossil built for cygwin.
> I use "fossil diff | tr -d '\r'" to overcome that.
> You may also want to set a gdiff-tool, and use 'fossil gdiff', if you have
> GNU diffutils available for example. I use that to get diffs in unified
> format.
>
>
> Fossil is not taking any steps to insert extra CR characters in the output.
> The output of "fossil diff" is generated using printf(). Do you suppose that
> the windows implementation of printf() is trying to be "helpful" by converting
> NL to CRNL?
>
printf from standard c library does add an additional 0d, if:
* the file is opened as text
* the system uses 0d 0a as line break
* a 0a is written on stdout
So if we have a windows text file, stored in fossil including the 0d 0a's and
write multiple lines to stdout with a single printf("%s",...), each 0d 0a will
be written as 0d 0d 0a. The first 0d is from the original data, the second one
is inserted by printf.
The C library asumes, that text is internally stored only with \n as line
break. The 0d/0a vs 0d problem is solved during read/write, if files are opened
as text. I didn't check this, but i think, that fossil opens versioned files
binary, which is OK for creating correct diffs, but makes problems when
using simple printf-output.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
