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.

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 <jan.stolarek@p.lodz.pl> 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