ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Fix line endings (Bug #262)

Added by Eric Thomas at 2011-03-05 09:29 pm. Updated at 2011-05-29 07:03 pm.

Status:Closed Start date:2011-03-05
Priority:Normal Due date:
Assignee:Eric Davis % Done:

0%
Category:Refactoring
Target version:2.0.0
Remote issue URL: Affected version:

Description

Background

Upon doing a fresh clone of the chiliproject git repo, git reports many files as being changed when core.autocrlf is set to true.

git clone git://github.com/chiliproject/chiliproject.git
git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#    modified:   app/views/common/error.html.erb
#    modified:   app/views/projects/settings/_activities.rhtml
#    modified:   config/locales/en-GB.yml
#    modified:   config/locales/eu.yml
#    modified:   config/locales/lv.yml
#    modified:   config/locales/mk.yml
#    modified:   config/locales/mn.yml
....
...
..

This is really annoying and can be hard to tell what is going on at first glance.

Associated revisions

Revision 05a4c461
Added by Eric Davis at 2011-05-29 08:59 pm

[#262] Add a rake task to convert line endings to UNIX

Revision a85b6780
Added by Eric Davis at 2011-05-29 09:00 pm

[#262] Convert line endings to UNIX

History

#1
Updated by Eric Thomas at 2011-03-05 09:40 pm

Pull request here: https://github.com/chiliproject/chiliproject/pull/15

This is definitely one of those things that is subjective to pull in or not. I am always against the "fixing whitespace at end of line" commits since it screws up git blame (unless of course you use -w flag. But when I do a fresh clone of a repo, I expect to be at a clean state.

#2
Updated by Eric Thomas at 2011-03-05 11:23 pm

  • Status changed from Open to Ready for review

#3
Updated by Felix Schäfer at 2011-03-06 07:42 am

I've had several occurrences of funny line endings creeping in in otherwise unrelated lines in commits, so yay from me to include that.

#4
Updated by Eric Davis at 2011-03-07 11:01 pm

I don't know. This will make merging changes from Redmine difficult if not impossible for some files (they use mixed line endings).

#5
Updated by Holger Just at 2011-03-07 11:10 pm

Eric Davis wrote:

I don't know. This will make merging changes from Redmine difficult if not impossible for some files (they use mixed line endings).

This is a bad excuse for allowing bad style. In our code style guide, UNIX line endings are mandatory. I'd rather try to contribute the patch back to Redmine. My even Ack pukes on one file somewhere on an UTF-8 error (where I don't know really where), so we should really try to improve ChiliProject's code style.

#6
Updated by Eric Davis at 2011-03-07 11:27 pm

Holger Just wrote:

This is a bad excuse for allowing bad style.

You're not the one who has to spend hours trying to wade through changes upstream for a merge ;)

What if we fix it on unstable and leave master as it is for now? Master has a higher risk of merge errors for me.

#7
Updated by Felix Schäfer at 2011-03-20 10:10 am

Eric Davis wrote:

What if we fix it on unstable and leave master as it is for now? Master has a higher risk of merge errors for me.

I'd say we can pull that for 2.0.0, I'd volunteer to take care of it if everyone agrees on that target.

On a related topic: have we agreed on a style best practice? For example: should empty lines be completely empty or indented to the same level as the surrounding code? Hashes currently look { :like => this } or {:like => that}, sometimes they're {:even => askew }, what's best practice here? And so on.

#8
Updated by Eric Davis at 2011-03-21 11:40 pm

Felix Schäfer wrote:

I'd say we can pull that for 2.0.0, I'd volunteer to take care of it if everyone agrees on that target.

Sure, as long it is after I do the next upstream review (so right before release). We might want to script this into a rake task to catch new files too.

On a related topic: have we agreed on a style best practice?

In progress Code Standards.

For example: should empty lines be completely empty or indented to the same level as the surrounding code?

Empty. If git diff will show red/green for trailing whitespace.

Hashes currently look { :like => this } or {:like => that}, sometimes they're {:even => askew }, what's best practice here?

I use {:key => value, :key => value} for single line hashes.

#9
Updated by Eric Davis at 2011-05-20 10:45 pm

Marking this as 2.0.0 so we make sure to do it.

  • Target version set to 2.0.0
  • Assignee set to Eric Davis

#10
Updated by Eric Davis at 2011-05-29 07:03 pm

I added a rake task (code:fix_line_endings) that will go through all of the code and convert them to UNIX line endings using the utility "fromdos" (05a4c4616f). Then I ran the conversion on our code (a85b6780d2) and merged the results into unstable.

  • Status changed from Ready for review to Closed

Also available in: Atom PDF