Massive detabbing of the source

Richard Eisenberg eir at
Fri Jan 18 18:08:23 CET 2013

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 at> 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.
> >
> >-tabs-in-certain-files-e-g-cpp-h-cmakeli
> >
> There is already such a hook:
> "We'd like to move away from tabs in the long term, and so a git hook on 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:
> Janek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list