Discussion:
Missing highlighted space changes in diff?
(too old to reply)
Andy Bradford
2014-03-01 19:17:59 UTC
Permalink
Hello,

I was perusing the recent commits and noticed that the web UI does not
highlight (in red) the actual changes here:

http://www.fossil-scm.org/index.html/info/3df526ca41

On the other hand, fossil diff --tk does actually work correctly:

fossil diff --tk --from 81162e791f --to 3df526ca41

Andy
--
TAI64 timestamp: 400000005312328a
Jan Nijtmans
2014-03-03 11:26:27 UTC
Permalink
Post by Andy Bradford
I was perusing the recent commits and noticed that the web UI does not
http://www.fossil-scm.org/index.html/info/3df526ca41
fossil diff --tk --from 81162e791f --to 3df526ca41
Well, joel started fixing this in the "diff-eolws" branch, and I did
some additional enhancements there. Feedback welcome!

Regards,
Jan Nijtmans
Joel Bruick
2014-03-04 01:42:08 UTC
Permalink
Post by Jan Nijtmans
Post by Andy Bradford
I was perusing the recent commits and noticed that the web UI does not
http://www.fossil-scm.org/index.html/info/3df526ca41
fossil diff --tk --from 81162e791f --to 3df526ca41
Well, joel started fixing this in the "diff-eolws" branch, and I did
some additional enhancements there. Feedback welcome!
Thanks for all the enhancements, Jan. One thing I want to argue, though,
is that diff --tk shouldn't ignore whitespace by default. At the very
least, it shouldn't ignore leading whitespace, which could lead to some
unpleasant surprises for people using Fossil with a language like
Python. And even then, we'll need to add another option for people that
want to force display of trailing whitespace changes with diff --tk.
Andy Bradford
2014-03-04 04:38:10 UTC
Permalink
Thanks for all the enhancements, Jan. One thing I want to argue,
though, is that diff --tk shouldn't ignore whitespace by default.
I would further argue that the web UI also should not ignore whitespace
by default.

The first thing I did to test the diff-eolws branch is with --tk and now
I see ``whitespace changes only'' and also look at the referenced commit
in the web UI.

I deal a lot with python and whitespace is significant.

Why should whitespace-only changes be hidden unless specifically
requested (or otherwise indicated by user preference in some fashion)?

I would vote to leave the original behavior (with a slight fix to
correct the web UI), but make it possible for the user to express a
preference to hide whitespace-only changes.

Andy
--
TAI64 timestamp: 40000000531558d5
Jan Nijtmans
2014-03-04 08:20:28 UTC
Permalink
Post by Andy Bradford
I would vote to leave the original behavior (with a slight fix to
correct the web UI), but make it possible for the user to express a
preference to hide whitespace-only changes.
Well, the original behavior was wrong, Joel proved that by its
off-by-one fix. Looking at the code, the intention was to ignore
eol-whitespace by default but sometimes that didn't work.

That said, I would prefer too the default being NOT to ignore
whitespace, that's what most other SCM's do. Except for
annotations, then it is useful to ignore all whitespacing.
Something like:
<http://fossil-scm.org/index.html/info/28b39cc516>

Is that getting nearer to what's really desired?

Thanks!
Jan Nijtmans
Andy Bradford
2014-03-04 15:18:48 UTC
Permalink
That said, I would prefer too the default being NOT to ignore
whitespace, that's what most other SCM's do. Except for annotations,
then it is useful to ignore all whitespacing.
Why is it useful to ignore all whitespace for annotate/blame? Am the
only one who I wants to know who's introducing spurious space changes?
:-) If I look at the annotate for:

http://www.fossil-scm.org/index.html/annotate?checkin=3df526ca41bde756&filename=src/checkout.c&log=1&limit=-1

The number 1 checkin listed is:

2014-02-28 check-in 3df526ca41 artifact a584a28bf3

But I cannot find any lines that show 3df526ca41. If I look at line 162,
it is annotated with:

d13054ce84 2010-10-26 162:

This seems confusing to me. Previously Fossil would show:

3df526ca41 2014-02-28 162:

Which in my opinion is the more correct behavior.
<http://fossil-scm.org/index.html/info/28b39cc516>
Is that getting nearer to what's really desired?
Yes, this actually looks quite nice! I also like the addition of the
``ignore whitespace'' button. I wasn't certain if this should be a
preference stored in the DB or a button---I think the button is more
convenient.

Thanks,

Andy
--
TAI64 timestamp: 400000005315eefb
Joel Bruick
2014-03-05 02:46:26 UTC
Permalink
Post by Jan Nijtmans
That said, I would prefer too the default being NOT to ignore
whitespace, that's what most other SCM's do. Except for
annotations, then it is useful to ignore all whitespacing.
<http://fossil-scm.org/index.html/info/28b39cc516>
Is that getting nearer to what's really desired?
I've made a few more changes. I'm happy with where it's at now unless
you notice anything else. Thanks, Jan.
Andy Bradford
2014-03-05 06:25:04 UTC
Permalink
I've made a few more changes. I'm happy with where it's at now unless
you notice anything else. Thanks, Jan.
Yes, it is coming along very nicely.

Please consider the following for inclusion:

http://www.fossil-scm.org/index.html/info/f1e99a5a40

My most heavily used Fossil includes a lot of Python and with the recent
changes, Fossil annotate/blame now renders a function entirely devoid of
whitespace:

def f(a):
b = a + 1
return b

Thanks,

Andy
--
TAI64 timestamp: 400000005316c363
Jan Nijtmans
2014-03-05 06:38:05 UTC
Permalink
Post by Andy Bradford
My most heavily used Fossil includes a lot of Python and with the recent
changes, Fossil annotate/blame now renders a function entirely devoid of
b = a + 1
return b
That's a bug which still needs to be fixed. I'll have a look at that.

For the annotate pages I would prefer the default behavior
to be to ignore whitespaces. See for example the following
lines:

<http://fossil-scm.org/index.html/artifact/c31113fe7e?ln=1711-1713>

Then annotate this page and see who wrote those lines??? It
will give you the answer: joel.
But ... If you annotate the previous version of this file,
you will see that the real author of those lines is dhr:
<http://fossil-scm.org/index.html/info/a2e7472d0fa04132>

All joel did was remove an if() around those lines, thereby
changing the indent. Does that make joel the author?
I think not! The "diff-eolws" branch gives the correct
answer. Your addition gives the correct answer after
pressing the "Ignore Whitespace" button.

Regards,
Jan Nijtmans
Andy Bradford
2014-03-05 06:51:19 UTC
Permalink
All joel did was remove an if() around those lines, thereby changing
the indent. Does that make joel the author? I think not! The
"diff-eolws" branch gives the correct answer. Your addition gives the
correct answer after pressing the "Ignore Whitespace" button.
It makes Joel the author of the most recent change to that line, yes,
and Fossil has not lost the history of who made the non-whitespace
changes. Also, clicking the button to reveal the non-whitespace change
is no more ``correct'' than if Joel had instead changed ``Listening'' to
``listening'' on one of those lines. It would still show Joel as the
``author'' of that line, but really he simply made a minor modification
to it while drh was the original author. Should Fossil be concerned
about authors of bytes in annotate/blame?

What is the ``correct answer'' if not the current line of text that
exists in checkin a2e7472d0fa04132?

Andy
--
TAI64 timestamp: 400000005316c98a
Jan Nijtmans
2014-03-05 09:08:00 UTC
Permalink
Post by Andy Bradford
Also, clicking the button to reveal the non-whitespace change
is no more ``correct'' than if Joel had instead changed ``Listening'' to
``listening'' on one of those lines. It would still show Joel as the
``author'' of that line, but really he simply made a minor modification
to it while drh was the original author. Should Fossil be concerned
about authors of bytes in annotate/blame?
Sorry, I respectfully disagree. Changing "Listening" to "listening" is
a real change inside the string, indentation (sol-whitespace) and
eol-whitespace (such as \r preceding \n) is generally considered
irrelevant for annotation, because it is before/after the 'actual' line.
In-between spacing, that's a different issue: Git's "blame" command
has a -w option for that purpose.... which
is much different from what you are proposing).

Actually, the "-w" option added to the diff commands/pages is
not 100% equal to git's "-w" option either: In git it means
--ignore-all-space, which is more forgiving than the sum of
-ignore-space-at-sol and --ignore-space-at-eol. Fossil could
be extended to handle the --ignore-all-space and
--ignore-space-change options too, but I don't think anyone
would note the difference. I consider this out-of-scope for the
"diff-eolws" branch (which should have been named
"diff-solws-and-eolws"......)

I think the "diff-eolws" is good to be merged to trunk (the annotation
indenting bug is fixed now), but I wait for Joel (and possible other
people interested)'s judgement.

Happy testing!

Regards,
Jan Nijtmans
Stephan Beal
2014-03-05 11:39:11 UTC
Permalink
Post by Jan Nijtmans
Post by Andy Bradford
Also, clicking the button to reveal the non-whitespace change
is no more ``correct'' than if Joel had instead changed ``Listening'' to
``listening'' on one of those lines. It would still show Joel as the
``author'' of that line, but really he simply made a minor modification
to it while drh was the original author. Should Fossil be concerned
about authors of bytes in annotate/blame?
Sorry, I respectfully disagree. Changing "Listening" to "listening" is
By removing the "if", Joel changed the semantics (not only the indentation)
of the code. i would argue that he is indeed the one who should be "blame"d
in that case.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Jan Nijtmans
2014-03-05 12:10:07 UTC
Permalink
Post by Stephan Beal
Post by Jan Nijtmans
Post by Andy Bradford
Also, clicking the button to reveal the non-whitespace change
is no more ``correct'' than if Joel had instead changed ``Listening'' to
``listening'' on one of those lines. It would still show Joel as the
``author'' of that line, but really he simply made a minor modification
to it while drh was the original author. Should Fossil be concerned
about authors of bytes in annotate/blame?
Sorry, I respectfully disagree. Changing "Listening" to "listening" is
By removing the "if", Joel changed the semantics (not only the indentation)
of the code. i would argue that he is indeed the one who should be "blame"d
in that case.
I can see both arguments very well. What's a pity is that the "diff-eolws"
branch started with diff behavior correction. Annotation uses the diff
logic, but I would like to keep this separate from the work that has been
done on this branch.

Therefore I reverted the "diff-eolws" branch diffFlags to what they
are in trunk now: DIFF_IGNORE_EOLWS.

Question to anyone interested:
What should be the diffFlags used for blame/annotate
1) DIFF_IGNORE_EOLWS (the current behavior, ignoring all
end-of-line spacing)
2) DIFF_IGNORE_SOLWS|DIFF_IGNORE_EOLWS (my preference, ignoring
all start-of-line and end-of-line spacing)
3) 0: Any difference in spacing is considered different
4) Any other flag, to-be-implemented.

Thanks for all reactions!

Regards,
Jan Nijtmans
Joel Bruick
2014-03-05 19:37:35 UTC
Permalink
Post by Jan Nijtmans
Therefore I reverted the "diff-eolws" branch diffFlags to what they
are in trunk now: DIFF_IGNORE_EOLWS.
Sounds good. Let's get this bug-fix-turned-feature branch into trunk! :)
Post by Jan Nijtmans
What should be the diffFlags used for blame/annotate
1) DIFF_IGNORE_EOLWS (the current behavior, ignoring all
end-of-line spacing)
2) DIFF_IGNORE_SOLWS|DIFF_IGNORE_EOLWS (my preference, ignoring
all start-of-line and end-of-line spacing)
3) 0: Any difference in spacing is considered different
4) Any other flag, to-be-implemented.
My personal preference is for (1), as EOL whitespace is practically
never worth caring about in any way (although, as Martin pointed out,
that isn't always the case). I'd also guess that it makes blame/annotate
more useful for the majority of users than (3), but maybe I'm wrong on
that. I wouldn't argue against (3) as the default, though.
Stephan Beal
2014-03-05 20:26:07 UTC
Permalink
Post by Jan Nijtmans
What should be the diffFlags used for blame/annotate
My personal preference is for (1), as EOL whitespace is practically never
worth caring about in any way (although, as Martin pointed out, that isn't
always the case). I'd also guess that it makes blame/annotate more useful
for the majority of users than (3), but maybe I'm wrong on that. I wouldn't
argue against (3) as the default, though.
On the "principal of least surprise," i've got to go with #3 (any change
is-a change). i suspect that doing otherwise will lead to confusion
downstream at point.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Ramon Ribó
2014-03-05 21:39:50 UTC
Permalink
I can agree to treat space at the end of line as a difference. However, the
end of line marker, be it "\n" or "\r\n" should be treated as equal. I
really cannot imagine a situation where this difference can be
significative.

Please note that languages like C, C++ or TCL do not distinguish between
these markers when reading a text file. They return exactly the same.

RR
Post by Stephan Beal
Post by Jan Nijtmans
What should be the diffFlags used for blame/annotate
My personal preference is for (1), as EOL whitespace is practically
never worth caring about in any way (although, as Martin pointed out, that
isn't always the case). I'd also guess that it makes blame/annotate more
useful for the majority of users than (3), but maybe I'm wrong on that. I
wouldn't argue against (3) as the default, though.
On the "principal of least surprise," i've got to go with #3 (any change
is-a change). i suspect that doing otherwise will lead to confusion
downstream at point.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Jan Nijtmans
2014-03-05 21:57:51 UTC
Permalink
Post by Ramon Ribó
I can agree to treat space at the end of line as a difference. However, the
end of line marker, be it "\n" or "\r\n" should be treated as equal. I
really cannot imagine a situation where this difference can be
significative.
I can: It allows to detect when people use an editor which changes
all LF's to CRLF and then commit this change without realizing
that that's an unnecessary burden to fossil. Much
better is allowing fossil to warn for this situation and even
letting fossil do the CRLF->LF conversion for you.

Regards,
Jan Nijtmans
Jan Nijtmans
2014-03-05 22:57:51 UTC
Permalink
Post by Ramon Ribó
I can agree to treat space at the end of line as a difference. However, the
end of line marker, be it "\n" or "\r\n" should be treated as equal.
<http://fossil-scm.org/index.html/info/4e6cfaf8f8>

Rather easy to implement, I couldn't resist myself doing that. Making
that the annotate/blame default could be option #4.

Regards,
Jan Nijtmans
Jan Nijtmans
2014-03-05 21:52:04 UTC
Permalink
Post by Stephan Beal
On the "principal of least surprise," i've got to go with #3 (any change
is-a change). i suspect that doing otherwise will lead to confusion
downstream at point.
Since that seems to be the mostly preferred option, that's on trunk now.
(it's easy to change anyway)

Happy continued testing.

Regards,
Jan Nijtmans
Andy Bradford
2014-03-06 04:12:47 UTC
Permalink
Post by Jan Nijtmans
Happy continued testing.
I've been testing on the diff-eolws branch and it all looks and works
very nice. Thanks for fixing the button that I introduced and didn't
realize it didn't honor the Show Log button.

Andy
--
TAI64 timestamp: 400000005317f5e2
Jan Nijtmans
2014-03-06 07:52:12 UTC
Permalink
Post by Andy Bradford
Post by Jan Nijtmans
Happy continued testing.
I've been testing on the diff-eolws branch and it all looks and works
very nice.
Well, it was your idea adding this button! I'm +1 for merging
this to trunk (leaving you the honor, so blame/annotate will
show the right info). I tested it too, and it indeed works fine.

Regards,
Jan Nijtmans

Doug Franklin
2014-03-05 14:59:50 UTC
Permalink
Post by Stephan Beal
By removing the "if", Joel changed the semantics (not only the
indentation) of the code. i would argue that he is indeed the one who
should be "blame"d in that case.
In Python, changing that indentation does indeed change the semantics.
It changes which block contains the line.
--
Thanks,
DougF (KG4LMZ)
Martin Gagnon
2014-03-05 12:14:20 UTC
Permalink
Post by Jan Nijtmans
Post by Andy Bradford
Also, clicking the button to reveal the non-whitespace change
is no more ``correct'' than if Joel had instead changed ``Listening'' to
``listening'' on one of those lines. It would still show Joel as the
``author'' of that line, but really he simply made a minor modification
to it while drh was the original author. Should Fossil be concerned
about authors of bytes in annotate/blame?
Sorry, I respectfully disagree. Changing "Listening" to "listening" is
a real change inside the string, indentation (sol-whitespace) and
eol-whitespace (such as \r preceding \n) is generally considered
irrelevant for annotation, because it is before/after the 'actual' line.
In-between spacing, that's a different issue: Git's "blame" command
has a -w option for that purpose.... which
is much different from what you are proposing).
May be I'm a bit pedantic on those kind of thing, but I really think a
diff and blame should show all the diff by default.

I like to keep the code clean, with uniform line ending and no extra
space at the end of lines etc... Per example, on the fossil project
itself, there's a style guideline: 2 spaces indentation, no tabs, unix
line ending etc... If someone commit and all indentation become 4
spaces, I want to know right away and blame/annotate page should
consider it like a change.

Sometimes space at the end of the line can break the code and generate
compilation error.
Example: multi-lines macros in C.

#define MY_MACRO(a, b) do { \
int var=0; \
if ( .. ) { \
...; \
} \
while(0)

Or when using EOT markers on shell script, I want to know if It's gonna
produce extra space on the output or if there's an extra space before the
EOT marker (which break the script)

cat <<EOT
some text
on multiple lines
EOT

[snip]

In those 2 cases, it's not only esthetics's changes, so how fossil can
make the difference without re-implementing all language parser of the
world ?

Regards,
--
Martin G.
Andy Bradford
2014-03-05 15:44:51 UTC
Permalink
Post by Jan Nijtmans
Sorry, I respectfully disagree. Changing "Listening" to "listening" is
a real change inside the string, indentation (sol-whitespace) and
eol-whitespace (such as \r preceding \n) is generally considered
irrelevant for annotation, because it is before/after the 'actual'
line.
With respect to what Fossil blame/annotate should be concerned about, I
don't see any difference. Blame/annotate show a list of checkins that
affect a given artifact and hiding some checkins because they have
particular data in them seems antithetical to change tracking software.

I agree that \r and \n are genrally considered irrelevant for compilers,
and other tools that might interpret those files, but should a tool that
is designed to track changes ignore some changes by default? Certainly,
some people might prefer to not see those changes, which is why I think
it's a good idea to have the ``ignore'' options.
Post by Jan Nijtmans
In-between spacing, that's a different issue: Git's "blame" command
has a -w option for that purpose.... which is much different from what
you are proposing).
I don't think Fossil needs to have feature parity with Git. :-) I
started using Fossil because I couldn't stand the way Git does some
things.
Post by Jan Nijtmans
I think the "diff-eolws" is good to be merged to trunk (the annotation
indenting bug is fixed now), but I wait for Joel (and possible other
people interested)'s judgement.
Thank you for the work on this. It certainly turned out more than I
originally envisioned when I first saw the difference in behavior
between diff --tk and the UI.

Cheers,

Andy
--
TAI64 timestamp: 4000000053174696
Stephan Beal
2014-03-05 16:32:17 UTC
Permalink
Post by Andy Bradford
With respect to what Fossil blame/annotate should be concerned about, I
don't see any difference. Blame/annotate show a list of checkins that
...is designed to track changes ignore some changes by default? Certainly,
some people might prefer to not see those changes, which is why I think
it's a good idea to have the ``ignore'' options.
+1 on all points (except that i'm ambivalent about the ignore globs).
Post by Andy Bradford
Post by Jan Nijtmans
In-between spacing, that's a different issue: Git's "blame" command
has a -w option for that purpose.... which is much different from what
you are proposing).
I don't think Fossil needs to have feature parity with Git. :-)
+1
Post by Andy Bradford
I started using Fossil because I couldn't stand the way Git does some
things.
i used fossil before git and simply don't get along with git - we always
fight like cats and dogs. git makes me feel really dumb, and i don't like
that ;).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Stephan Beal
2014-03-04 11:37:27 UTC
Permalink
Post by Andy Bradford
I would further argue that the web UI also should not ignore whitespace
by default.
FWIW: +1

Space is important. Just ask python developers who've had their cat step on
their keyboard and thereby change the meaning of (without breaking) their
program.

I would vote to leave the original behavior (with a slight fix to
Post by Andy Bradford
correct the web UI), but make it possible for the user to express a
preference to hide whitespace-only changes.
+1, assuming that behaviour is correct/fixed (it's got some broken cases
according to the response from Jan).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Ramon Ribó
2014-03-04 11:57:56 UTC
Permalink
​I see no problem to consider space as a difference but I would not
consider line endings (linux/windows) a difference​ to be shown in diff or
annotate.

​RR​
Post by Stephan Beal
Post by Andy Bradford
I would further argue that the web UI also should not ignore whitespace
by default.
FWIW: +1
Space is important. Just ask python developers who've had their cat step
on their keyboard and thereby change the meaning of (without breaking)
their program.
I would vote to leave the original behavior (with a slight fix to
Post by Andy Bradford
correct the web UI), but make it possible for the user to express a
preference to hide whitespace-only changes.
+1, assuming that behaviour is correct/fixed (it's got some broken cases
according to the response from Jan).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Stephan Beal
2014-03-04 13:03:29 UTC
Permalink
Post by Ramon Ribó
I see no problem to consider space as a difference but I would not
consider line endings (linux/windows) a difference to be shown in diff or
annotate.
man isspace says:

isspace()
checks for white-space characters. In the "C" and "POSIX"
locales, these are: space, form-feed ('\f'), newline
('\n'), carriage return ('\r'), horizontal tab ('\t'), and
vertical tab ('\v').

i.e. "space" includes EOL characters, per long-standing tradition.

If a file differs only by line endings, its hash is still different, so
eliding EOL diffs by default could, IMO, be particularly confusing. Two
files, different hashes... no diffs? (That said, an option to disable them
as being treated as diffs would be very welcomed. :)
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Ramon Ribó
2014-03-04 14:41:10 UTC
Permalink
I see no problem in the file being marked as different but the difff
showing no actual diff. If necessary, it is possible to add a message "only
end of line differences".

The point is that, if you consider end-line as differences for "diff" or
for "annotate" you will be showing a difference mark for every line, which
is not too much useful for the user.

If you prefer to go to the technical explanation, you can say: a
differences algorithm can only be applied to text files. Text files are, by
definition, a collection of lines separated by "end of line" markers. We
understand end of line markers as either "\n" or "\r\n" and we do not mind
which of them is used.
In fact, if you open a text file in either C, C++ or in TCL (in text mode),
"\r\n" is converted into "\n" to all effects.

​RR
Post by Stephan Beal
Post by Ramon Ribó
I see no problem to consider space as a difference but I would not
consider line endings (linux/windows) a difference to be shown in diff or
annotate.
isspace()
checks for white-space characters. In the "C" and
"POSIX" locales, these are: space, form-feed ('\f'), newline
('\n'), carriage return ('\r'), horizontal tab ('\t'), and
vertical tab ('\v').
i.e. "space" includes EOL characters, per long-standing tradition.
If a file differs only by line endings, its hash is still different, so
eliding EOL diffs by default could, IMO, be particularly confusing. Two
files, different hashes... no diffs? (That said, an option to disable them
as being treated as diffs would be very welcomed. :)
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Continue reading on narkive:
Loading...