git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: builtin conversion between tabs and spaces

From
Stefan Karpinski <stefan.karpinski@gmail.com>
Date
Oct 15, 2008, 20:55 UTC
Message-ID
<d4bc1a2a0810151355q283d7a4y7bf35a3423cf1d46@mail.gmail.com>
In-Reply-To
<48F58D1C.2040208@viscovery.net>
Show 6 quoted lines
>> This led me to wonder if it wouldn't make sense to have this
>> conversion ability built into git.
>
> This wouldn't help your case a lot. It is still at the discretion of each
> individual repository owner to enable the conversion. (You didn't mean to
> make this conversion mandatory, did you?)

This would all be completely discretionary, of course. I just thought that the issue was complicated enough and the problem of mixed spaces and tabs in source code ubiquitous enough that it might be worth "solving" correctly in git itself.

Show 7 quoted lines
> BTW, you don't need to change git code to achieve this. It's sufficient to
> install a suitable "clean" filter:
>
> echo "*.c filter=c-code" > .git/info/attributes
> git config filter.c-code.clean tabs2spaces
>
> where tabs2spaces is your utility that does the conversion.

That was the first thing I did—in ruby first, then in C. The ruby version is *way* too slow to use on any number of files—and the typical use case is that most of your files are source code and so will have this applied to them. On the other hand, the ruby script (or perl or whatever) is portable, so I can send it to my Windows-based developers and have them use it too.

But the speed issue is pretty crucial, so I rewrote the thing as an external C program, which is obviously much faster. But it's still noticably slower than native git checkout though. Worse still, now the filter script isn't portable, so I have to cross-compile it and give every developer the version that works on their platform and make sure that they have their path setup correctly, etc.

Having the conversion built into git would
  1) have native git checkout speed (I've tried it and it's not
noticable slower than normal git checkouts);
  2) be naturally portable to anywhere git works.

Now, if I thought this was a thing that would only benefit me, I would never bring it up. However, it seems like something that a lot of projects might want to use to ensure standard spacing in their source files. Moreover, since developers feel strongly about using tabs or spaces, it would be beneficial for individuals too. I think there's enough complex issues that solving it once-and-for-all might be worth a shot.

Previous: Johannes Sixt
Message 11 of 11 in “builtin conversion between tabs and spaces”
  1. Stefan KarpinskiOct 15, 2008
  2. Stefan KarpinskiOct 15, 2008
  3. Alex RiesenOct 15, 2008
  4. Stefan KarpinskiOct 15, 2008
  5. Jonathan del StrotherOct 15, 2008
  6. Stefan KarpinskiOct 15, 2008
  7. Stefan KarpinskiOct 15, 2008
  8. A Large Angry SCMOct 15, 2008
  9. Stefan KarpinskiOct 16, 2008
  10. Johannes SixtOct 15, 2008
  11. Stefan KarpinskiOct 15, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.