On 14.07.14 02:29, Benjamin R. Haskell wrote:
> If a file is checked into a git repo without the trailing newline,
> editing the file in Vim causes the newline to be added, which looks
> like a change, even if 'noeol' is set.
Errr ... this argument simply says that because someone with a broken
editor has mistakenly checked in a poorly formatted file, we should
refrain from repairing that defect.
Furthermore, since a check in after a Vim edit would be adding some
substantial change, in order to warrant the check in, it is simply a
highly benevolent bonus that the file format is simultaneously repaired.
It would in fact be a deplorably Bad Thing (TM) if EOL damaged files
were allowed to proliferate in public git (or other VCS) repositories,
so this example is in fact a strong argument for leaving Vim unchanged.
Years ago I had similar crap from (software development) team members
who knew no better than to use M$ platforms and editors, so their code
had DOS line endings (CRLF). I solved that by performing all CVS
operations myself, and utilising a wrapper function to de-DOS all files
before checking in. Problem gone!
For the case of distributed development, CVS provides the option of
internal "wrapper" functions, allowing automatic preprocessing of files
prior to check in. It would be surprising if GIT were deficient in this
area. Again, problem gone!
Erik
--
"... a decent text file must end with a LF. Vim fixes that for you (it always
has). If other tools omit that LF you need to fix those tools, not Vim."
- Bram Moolenaar
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment