Dnia czwartek, 17 stycznia 2013, Simon Peyton-Jones napisał:

But if you find files that are stable -- have not been modified for some months -- then yes you could detab them. This seems to be a good heuristic.

I'm unsure it's worth the bother Cleaner code is worth the bother :) Especially that is really not that much effort.

Janek

On Jan 18, 2013 10:17 AM, "Jan Stolarek" wrote:

...

I don't think it's worth the bother either: conflicts are a pain and slow down development, whereas tabs don't. (...) there certainly are a few active branches with large-scale changes. That's another good point.

I looked through the git history and it seems there are actually few tabbed files that weren't touched for the last 6 months. It follows that tabbed files that people work on are not being actually detabbed by them, unless the policy is to detab only the parts that are modified, not the whole file.

I won't do this massive detabbing of the whole source since it indeed could cause more problems than profits, but my opinion is that at some point detabbing should be just done or otherwise those -fno-warn pragmas and tabs will stay in the source code forever. Perhaps it would be a good idea to detab a bunch of files every month?

Well if this is true, then I think you could solve this simply by looking for this in a git commit hook or some other hook. http://stackoverflow.com/questions/3985463/prevent-pushes-to-git-containing-... https://github.com/mrc/git-hook-library Alexander

Then it's even easier. Update the hook to reject all tabs in source code files, wait 6 months, and start detabbing the remaining files. Then the probability of conflict should be pretty low. Alexander On Fri, Jan 18, 2013 at 1:46 PM, Jan Stolarek wrote:

Dnia piątek, 18 stycznia 2013, Alexander Kjeldaas napisał:

...

Well if this is true, then I think you could solve this simply by looking for this in a git commit hook or some other hook.

http://stackoverflow.com/questions/3985463/prevent-pushes-to-git-containing

...

-tabs-in-certain-files-e-g-cpp-h-cmakeli https://github.com/mrc/git-hook-library There is already such a hook:

"We'd like to move away from tabs in the long term, and so a git hook on darcs.haskell.org will reject series of commits that add tabs to a file that is currently tab-free. (Note that there are no restrictions on adding tabs to a file already containing them.)"

From: http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#TabsvsSpaces

Janek

I don't mind too much either way what happens here as I have no outstanding changes. However, I generally agree with the Simons. We've been slowly removing tabs over time and a little ugliness doesn't hurt for now. I also like that de-tabbing for me has been a big motivation to not simply de-tab, but to clean up those files in a larger sense. My 2 cents :). On 18 January 2013 09:08, Richard Eisenberg wrote:

I like Alexander's idea, but there's a subtle problem with it: Any sizeable change to one file requires (at least) small changes in several other files. Say X.hs has tabs. If I make a one-line change to X.hs, and you're in the middle of massive changes to X.hs, and I detab X.hs in the course of committing my one-line change, you have a bad merge in your future.

So, my suggestion would be to do what Alexander suggests, but essentially to make the error into a warning. When committing a file with tabs, the hook can report a list of all files containing tabs in them, encouraging the committer to detab any files they have made significant changes to. The commit would still go through, though. Then, after 6 months of that, we can change the warning into a proper error and/or do a massive full-sweep detabbing.

Richard

On Jan 18, 2013, at 8:03 AM, Alexander Kjeldaas wrote:

Then it's even easier. Update the hook to reject all tabs in source code files, wait 6 months, and start detabbing the remaining files. Then the probability of conflict should be pretty low.

Alexander

On Fri, Jan 18, 2013 at 1:46 PM, Jan Stolarek wrote:

...

Dnia piątek, 18 stycznia 2013, Alexander Kjeldaas napisał:

...

Well if this is true, then I think you could solve this simply by looking for this in a git commit hook or some other hook.

http://stackoverflow.com/questions/3985463/prevent-pushes-to-git-containing -tabs-in-certain-files-e-g-cpp-h-cmakeli https://github.com/mrc/git-hook-library There is already such a hook:

"We'd like to move away from tabs in the long term, and so a git hook on darcs.haskell.org will reject series of commits that add tabs to a file that is currently tab-free. (Note that there are no restrictions on adding tabs to a file already containing them.)"

From: http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#TabsvsSpaces

Janek

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs