Converting a Git repo from tabs to spaces (2016)

https://eev.ee/blog/2016/06/04/converting-a-git-repo-from-tabs-to-spaces/

by keybored • 1 year ago

48 105 1 year ago

eev.ee

Alifatisk2• 1 year ago

Why would you want to convert from tabs to spaces?

diggan5• 1 year ago

their mostly-Python codebase had always been indented with tabs

Tabs VS spaces isn't usually very important, but what's more important is that all the stuff is the same way. So if all the other codebases (in the same language) are using tabs, then make everything (in that language) use tabs. Consistency basically :)

Alifatisk2• 1 year ago

I agree.

gwbas1c7• 1 year ago

I used to agree with that, until I read this article. I would always use the IDE's default and "not care" as long as the code was consistent.

The problem with tabs is that they render as different widths in different contexts. For example, Visual Studio shows them as 5 spaces, but Github shows them as 8.

Puts me firmly in the spaces camp now.

mmastrac4• 1 year ago

Because it's the one true way, and tabs are WRONG.

Also Vim > Emacs, the new BSG was better than the old BSG, TNG is the best Trek, and all the other hashed-out flamewars of the 90's and 2000's. :)

evbogue• 1 year ago

There's a debate about new BSG being better than old BSG?

daneel_w4• 1 year ago

Because the latter is universal, and it can always align perfectly.

    # using tabs with tabsize 4
    
    some_func( eyesore,
                blah );
    
    some_func(
            eyesore,
            blah );
    
    some_func(
                eyesore,
                blah
            );

Asooka• 1 year ago

We use 4-wide tabs and in our code style it would be

    some_func(
        verylongarg0,
        verylongarg1
    );

Which I feel is the most readable option. If you have to break the args into a vertical list, you want to use the least amount of whitespace before each arg. It's also a bit easier to read with every term starting at a tab break.

SoftTalker• 1 year ago

Well, obviously tabs should always be 8 spaces.

DaiPlusPlus3• 1 year ago

and it can always align perfectly.

I'm firmly in Team Tab, and I want to arrest any misconception that us Tabbers would do anything as nonsensical as using our precious variable-width tab-stop chars for anything like column-aligning identifiers: we don't.

My very hard and fast rule is that tabs are for only indenting at the block level, while spaces are used for alignment after the initial tab chars; tabs must never be used on a line if preceded by any non-tab char.

Whereas I can't stand always-using-only-spaces-for-indenting-and-alignment - especially because when you're drag-selecting text most editors won't snap your selection to the indent level, so you get RSI in your wrist from having to make micro-movements to make sure you don't select more - or less - spaces than the intended indent. ...or worse: when moving the caret via the keyboard and having to tap your arrow-keys 4 or 8 times per indent instead of just once.

You spaces-only people are totally spaced out, man.

zahlman3• 1 year ago

My style using spaces is

  some_func(
      eyesore,
      blah
  )

which would work just as well with tabs.

Many years ago, I used tabs, and set them to two-space indent. The former because the entire point is that tabs carry different semantic information - this is a level of indentation, not just making things align vertically - and allow each developer to set the indentation width to their preference. (The other comment from DaiPlusPlus explains the proper use of tabs, just as I did it.)

The latter because that makes them more square. Aesthetics matter.

I switched mostly out of peer pressure. But one argument I did find convincing is that setting some specific limit on line length - whether it's 72 or 78 or 80 or 100 or anything else - makes sense, and letting people change the amount of indentation defeats that purpose. That is: the guy who likes 8-space indents can't actually have them, because it produces a horizontal scroll for code that "conformed to the style guidelines" when written by the 2-space guy.

But now I alias names, break up complex subexpressions etc. to avoid questions of how to split code across multiple lines - and most lines in my code are nowhere near any such length limit. And I write short functions, so there aren't enough levels of indentation to matter.

And I use 4-space indents, because standards have value after all.

ooterness• 1 year ago

To make more money:

https://stackoverflow.blog/2017/06/15/developers-use-spaces-...

zahlman3• 1 year ago

My best guess: using spaces selects for developers who understand how their editor works (which correlates with higher overall cluefulness), because they'd go insane otherwise.

y-curious2• 1 year ago

https://youtu.be/oRva7UxGQDw?si=XUvMWQqIF-Uy1gNp

rascul• 1 year ago

This is the discussion I came here for.

mcdonje2• 1 year ago

Because they're deranged control freaks who need to convert a single character that is semantically a tab into multiple characters that are an opinionated representation of a tab.

Devs: We need to separate concerns and split the view from the model.

Also devs: Someone might view the code differently!!1!

maw• 1 year ago

A codebase that's formatted notgivingashittily is an accessibility issue. It's not just deranged control freakism.

Maybe Yelp's codebase was otherwise clean, but aside from golang projects (and the Linux kernel) I've come to associate tabs with unreadable slop code. Maybe your experience is different.

Defletter• 1 year ago

I've been firmly pro-spaces ever since I discovered there was an everlasting war over this, and it came about primarily over documentation. Say you're writing documentation within a /***/ block, so each line is prefixed by three characters. Now say your documentation includes a code snippet. Or lets say that particular sections of the documentation (such as JavaDoc's @see) are indented so each line always starts after the @see. You end up with documentation indented with spaces because it's the only way to ensure consistency. And if you're doing it with your documentation... why not your code too?

However, my conviction has since been tested by Dart which opinionatedly forces you to use two-space indentation. There's no way to disable this and its IDE plugins enforce the style. I just find it so difficult to read, even with Rainbow Brackets. I yearn for Dart to use tabs just so I can configure the tabs to appear as four-space indentation. Or better yet, stop trying to coerce how people write their own code.

david2ndaccount• 1 year ago

Tabs are a control character and have no business being in a text file. Do you use ascii record separator characters too?

IvyMike• 1 year ago

Galaxy brain: indent using U+001F Unit Separator

imiric2• 1 year ago

No, but I do use Line Feed and Carriage Return.

yjftsjthsd-h• 1 year ago

Do you use ascii record separator characters too?

The only reason I don't use them is because nothing supports/expects/shows them. The alternate history where we properly use them is a world where CSV isn't needed and we're better off for it.

DidYaWipe4• 1 year ago

What an absurd statement.

mmastrac4• 1 year ago

I wish Git had a way to "skip" a commit for blame for mechanical changes like this. It's the one big shortcoming I keep running into. A commit should be able to be marked as "blame-free" and git blame should then walk up to the parent commit.

It might be expensive to compute but man it would be so useful.

Edit: TIL about .git-blame-ignore-revs. I am the 1 in 10000 for this one today, thanks.

joshstrange2• 1 year ago

`.git-blame-ignore-revs` is probably what you are looking for

Example: https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...

y-curious2• 1 year ago

My one gripe with this is that devs need to point their IDE to the file in the IDE settings. When I implemented .git-blame-ignore-revs, I got a lot of people complaining about blame disappearing completely and I had to point them all to editing IDE settings

js22• 1 year ago

It does. See `--ignore-revs-file`:

https://git-scm.com/docs/git-blame

You can configure a default:

  git config blame.ignoreRevsFile .git-blame-ignore-revs

GitHub supports it too:

https://docs.github.com/en/repositories/working-with-files/u...

I'm really curious though. This is a feature you've wished for: have you never bothered to run `man git-blame`, `git blame --help`, or Google for it? Git has supported it for ages and it's a trivially easy feature to find. Using your own description:

https://www.google.com/search?hl=en&q=git%20skip%20commit%20...

mmastrac4• 1 year ago

I've been using Git since the early 2010s and this feature was released in Aug 2019 (https://github.blog/open-source/git/highlights-from-git-2-23...).

You don't think I looked for it for the first 7-8 years of using Git at least a few times and came up empty? Seems a little uncharitable. Hacker News is a place to learn about stuff, not be chided for missing a point note in a release.

Come on man, you've been using HN for almost as long as I have. Be curious, treat people's comments with charity, continue the life-long learning tradition.

Obligatory XKCD lucky 10,000 link: https://xkcd.com/1053/

IshKebab2• 1 year ago

It would be a lot more usable if you could put that info in the commit.

jayd162• 1 year ago

The annoying thing about git is that you can't really set this kind of stuff up globally for a project w/o digging into some custom hook solutions. They should really have some kind of default config file with all these things. I really don't understand why everything needs to be per user settings ONLY.

McP• 1 year ago

Nice to see ignore-revs getting some love :)

I originally wrote it because I wanted to do a mass-refactoring to llvm-project to change its weird naming convention and "it will mess up git blame" was an objection that was raised. Getting ignore-revs landed took many iterations over several months (thanks Barret!) and at the end of it I felt so drained that I didn't have the energy to do the mass refactoring I originally planned. Oh well. Maybe someday.

patrickthebold• 1 year ago

Is .git-blame-ignore-revs what you are looking for?

braiamp• 1 year ago

`blame -w` ignores the ones that are described in the article.

PhilipRoman• 1 year ago

git-blame-ignore-revs is great, but ultimately a half measure. Replace blame with log -L

kwk1• 1 year ago

See also `git blame -w`

hannasm• 1 year ago

Everybody else here has a fantastic solution to your complaint but wouldn't it be even better to think big here, and wish that stupid whitespace formatting issues weren't something that git was tokenizing to begin with?

florbo• 1 year ago

Whitespace is important for a myriad of reasons, so the implementation makes sense to me. However, I would love to see git have configuration surrounding syntax awareness. That's a huge undertaking, though, but one can dream.

joshstrange2• 1 year ago

Then, commit! As per Yelp tradition when rewriting every single file in the whole codebase, I attributed the commit to Yelp’s lovable mascot Darwin. It stands out better in git blame, and it preserved the extremely critical integrity of my commit stats.

Interesting, I fully expected this blog post to touch on `.git-blame-ignore-revs` as a way to not "pollute" the git history but I'm not sure when that "came out". I found a Github issue from 2021 asking for support to be added to Github so it may just be newer.

How do other people feel about this? Massive code changes across the codebase? Where I work some people are (understandably) concerned about it "ruining" `git blame` or IDE tools to blame. It's not useful to see "Converting to spaces!" on every line you want more context on. Yes, you can step further back but that's always been a little awkward for me (at least in IntelliJ) but maybe I'm missing something. I just find it incredibly helpful to understand the context of why a line was last changed and I'd want to skip over any edits like tabs->spaces.

matsemann• 1 year ago

What if one instead rewrote the last commit for each line to use spaces for that line? Or just rewrite the whole history to have used spaces. Might break something in the history if one were to check out an old commit, though. And makes it hard to revert if something breaks due to changing to spaces (impossible to find the offender in the diff).

_Algernon_• 1 year ago

Or just rewrite the whole history to have used spaces.

Ah, yes. The 1984 approach to coding

woodrowbarlow• 1 year ago

`git blame -w` ignores whitespace-only changes, for what it's worth.

radlad• 1 year ago

Added to Git in 2019: https://github.com/git/git/commit/209f0755934a0c9b448408f9b7...

Supported on Github in 2022: https://github.blog/changelog/2022-03-24-ignore-commits-in-t...

zahlman3• 1 year ago

I fully expected this blog post to touch on `.git-blame-ignore-revs` as a way to not "pollute" the git history but I'm not sure when that "came out".

Per https://news.ycombinator.com/item?id=43869828, it appeared August 2019 - so, indeed too late for OP.

e: Also, FTA:

Blame is not, in fact, permanently ruined. git blame -w ignores whitespace-only changes.

gwbas1c7• 1 year ago

FYI: If you're in the .net ecosystem, you can choose your tabbing style (tabs or spaces) with an .editorconfig file. Then running "dotnet format" will change everything for you. (And, if you use github, you can create actions to assert that the .editorconfig is followed.)

diggan5• 1 year ago

FWIW: EditorConfig isn't a ".net ecosystem" thing but works across a ton of languages, editors and IDEs: https://editorconfig.org/

Also, rather than using GitHub Actions to validate if it was followed (after branch was pushed/PR was opened), add it as a Git hook (https://git-scm.com/docs/githooks) to run right before commit, so every commit will be valid and the iteration<>feedback loop gets like 400% faster as you don't have to wait for Actions to finish.

gwbas1c7• 1 year ago

Git hooks require environment-specific configuration. CI enforcement makes sure that everyone follows the rules, even if they "forget" to set up the git hook.

Also: dotnet format is kind of slow, which is why they aren't used where I work.

gwbas1c7• 1 year ago

One way or another, you must get this block in your devs’ Git configuration

Uhm, things like this should be enforced in CI. IE, as a rule that must pass in order for a pull request to be merged.

kgwxd• 1 year ago

I never understood why programmers universally like fixed width fonts, but then about half want just 1 of those characters to be batshit crazy.

gwbas1c7• 1 year ago

One funny anecdote: I once did a similar cleanup on a codebase that was mostly spaces, but a few tabs slipped in. (I just did a find and replace on \t -> " ")

Suddenly, one unit test broke. On closer inspection, whoever wrote it put a tab character into a string. I changed the test to use \t.

baobun• 1 year ago

I would just approach this like text. Something like:

    find -type f -name '*.py' -exec sed -i 's/^\t/    /' {} \+

, until you don't see a diff

Seems simpler to adjust that general approach to whatever codebase and replacement.

s09dfhks• 1 year ago

what is this furry tomfoolory

user9999999999• 1 year ago

whitespace is a terrible block scope definition, its literally using 'invisible' characters to determine block scope! just use semi colons. LONG LIVE SEMI COLONS ;;;;;;;;;;;

zzo38computer• 1 year ago

Note that some files will need tabs such as Gopher menus and Makefile.

rurban• 1 year ago

A bit overly complicated. I have to do such things pretty often, esp. with cygwin codebases and sloppy maintainers.

find . -name *.py -exec expand -t4 '{}' \;

git commit -am'chore: expand all py tabs to spaces'

and this for all branches. Usually also clang-format and dos2unix.

No need for .gitattribute filters. And no magic rewrites, just a commit.

Converting a Git repo from tabs to spaces (2016)

Related Stories