From: Scott Robison
Sent: Sunday, June 08, 2014 12:05 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] autocrlf like in Git?
* Several old time assemblers will choke on wrong line endings. Their
binaries cannot be updated as the source is no longer available. So, you
must edit code only in the right format or you’re out of luck.
This seems to be conflating the editing of assembly source with editing of
binaries for which source is no longer available. What am I missing?
What is not clear? Old assembly source may still be updated, as needed, to
support existing products. But the assembler used to convert this source to
binary cannot itself be updated as its source is no longer available, only
the binary survives. The assembly source is written for this assembler so
you’re stuck using it. For old projects that will eventually die, it's not
worth the effort creating a newer (better behaving) assembler, and possibly
converting all target source code to a possibly incompatible new assembler's
syntax introducing a whole bunch of new problems.
I also wrongly assumed the guys who maintain Git saw a reason for having
this option. I can promise you it wasn’t me who asked for it, so they
must have had nothing better to do than to add a useless feature in their
app that nobody ever needs.
Now this is maybe a slightly emotional response. No one has told you EOL
conversion is a useless feature, just that in their opinion that it doesn't
belong in a particular DVCS whose primary overriding concern is "store what
I tell you to store exactly as I have stored it". To me this makes sense,
particularly on a platform (unixen) that is notorious (to a fault maybe?)
of advocating tools do one thing and do it well.
In general, an SCM that is supposed to be used by various people each
working on a their own ‘random’ platform should be able to give to all of
them the impression that text files are normal text files, that is ‘normal’
according to their own system, not to the system of the person who initiated
the repo. Otherwise, repos should be marked as ‘Linux-only’, ‘Windows-only’,
‘Mac-only’, etc. and trying to open them in the wrong platform should fail
with a related error message. Do we agree so far? If not, there is no need
to read further.
Given that all text files contain their meaningful info in the part of the
file that is not the EOL marker, and the EOL marker is only there to assist
the underlying OS/library to be able to correctly load/process that text
file, changing those EOL at will to be compatible with the user’s current
platform is not a violation of any sanctity. If the platform’s tool cannot
deal with a text file in its own native format, then that tool is at fault,
nobody else. But if a tool cannot deal with a text file of a different
platform, we cannot blame the tool.
Finally, regarding a comment in another response about the complexity of
this change, as for the hash values computation, a stream can easily be
wrapped inside another routine that produces a normalized stream that is
then fed into the hash calculator. I really do not see the complexity.
Maybe I don't have enough decades in this job yet, who knows?
From: Scott Robison
Sent: Sunday, June 08, 2014 12:05 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] autocrlf like in Git?
On Jun 7, 2014 1:47 PM, <to...@acm.org> wrote:
Well, I can give a couple of personal examples that you easily try
yourselves:
* Windows side: Copy/Paste in Windows can not deal with LF endings
correctly. Example: PNotepad editor in Windows loads Linux files but
copy-pasting from it (for example) to other apps messes up all text (puts
it all in a single line).
Yes, though this is more a deficiency with a particular program than with
Windows at large. The fact is that the convention of "newline only as EOL
marker" is just a convention. CRLF is arguably more correct, particularly
given the era in which it was established.
* Linux side (vi): Have you tried editing a Windows text file under vi?
It shows all ^M (CRs) at the end of each line.
I have, and agree it is annoying, but that is an issue of vi choosing not to
handle alien text file formats.
* Several old time assemblers will choke on wrong line endings. Their
binaries cannot be updated as the source is no longer available. So, you
must edit code only in the right format or you’re out of luck.
This seems to be conflating the editing of assembly source with editing of
binaries for which source is no longer available. What am I missing?
I also wrongly assumed the guys who maintain Git saw a reason for having
this option. I can promise you it wasn’t me who asked for it, so they
must have had nothing better to do than to add a useless feature in their
app that nobody ever needs.
Now this is maybe a slightly emotional response. No one has told you EOL
conversion is a useless feature, just that in their opinion that it doesn't
belong in a particular DVCS whose primary overriding concern is "store what
I tell you to store exactly as I have stored it". To me this makes sense,
particularly on a platform (unixen) that is notorious (to a fault maybe?) of
advocating tools do one thing and do it well.
I agree that there are tools that will "do the wrong thing" with mixed or
alien EOL markers. My bread and butter is provided primarily by Windows
development, so I have to use Visual Studio extensively. It detects mixed
line endings on open and offers to normalize. Perhaps an email to vi or
emacs or [insert editor of choice] devs might convince them to change their
tools. :)
I think one of two potential solutions are possible here though:
1. Convince the devs to support hooks (which have their own issues as argued
in the past), particularly pre/post commit and post update hooks. In this
way tooling (such as tr or dos2unix/unix2dos) could be made to normalize
line endings after changes.
2. In the absence of hooks, relatively simple shell scripts could do the
exact same thing.
SDR
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
