7 ms·

Converting a Git repo from tabs to spaces (2016)

48 points by keybored 2y ago

Alifatisk 2y ago
Why would you want to convert from tabs to spaces?
- diggan 2y 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 :)
  - Alifatisk 2y ago
    I agree.
  - gwbas1c 2y 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.
    - diggan 2y ago
      > I would always use the IDE's default and "not care" as long as the code was consistent. I mean, "just use the IDE's default" isn't really agreeing, unless that's what your entire organization does too, and you all use the same IDE :)
      - gwbas1c 1y ago
        Pretty much everywhere I've worked everyone uses the same IDE. When someone doesn't, we make sure they know we aren't going to make too many accommodations for them.
        diggan 1y ago
        > Pretty much everywhere I've worked everyone uses the same IDE. FWIW, none of the places where I've worked has everyone used the same IDE (or an IDE at all, personally I use nvim so :shrug: ). Fun how the world is different for everyone :)
    - InsideOutSanta 2y ago
      > The problem with tabs is that they render as different widths in different contexts The funny thing is that this is why I prefer them. It means I control how indents render rather than the person who wrote the code.
      - mabster 2y ago
        I would agree, except that only deals with the left hand side of the code. We are also making decisions on the right hand side of the code to deal with lime width as well which only really works if all developers have the same tab size. Nowadays I just chuck format on save on all the code I deal with so I don't have to deal with any of this stuff anymore. If we take this to its longer conclusion though, it would be pretty good if our tooling supporting a difference between the view (using your own preferences) and storage (consistent code for committing to git or whatever).
        DidYaWipe 1y ago
        What? If you have lines that are too wide, you can 1. Change the tab width in your IDE 2. Turn on line-wrapping
        mabster 1y ago
        1. This problem is introduced by increasing the tab width, so this solution is basically "don't do that". 2. Line wrapping on something like C where you have braces is okay, but not with something like Python where the code now looks wrong. I'm in the spaces camp, but I was musing about this for the tabs camp because wanting to adjust the indentation seems reasonable. (My "favourite" convention was Luajit where the convention was: 2 spaces, until we got to 8 spaces, in which case tab.)
        DidYaWipe 1y ago
        Yep, that's why line-wrapping is #2. I can see why it'd be less acceptable for some languages.
    - DidYaWipe 1y ago
      This is an oft-repeated and utterly bogus argument. You can simply change how many spaces a tab is in your own IDE. And in decades of programming in IDEs from Borland to Visual C++ (since there were separate 16- and 32-bit versions) to Xcode... I've never seen one default to five spaces. Four spaces is, by far, the most common. People who don't understand tabs are akin to those who don't understand styles: Doomed to laboriously dick around with formatting, and make work for everyone else.
    - motorest 1y 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 is that everyone touching the project can and often does have different defaults. If you work on a professional setting, specially in legacy projects, you are bound to touch files where your changes comprise mainly of whitespace changes.
      - gwbas1c 1y ago
        That's why "clean up tabbing" projects happen.
    - ujkiolp 1y ago
      [flagged]
    - deleted 1y ago
      [deleted]
- mmastrac 2y 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 2y ago
    There's a debate about new BSG being better than old BSG?
    - mmastrac 2y ago
      I posit: For every topic of A vs B where A and B are related in some way, no matter how small, there exists an argument C where two people take increasingly opposed positions about which is better.
    - HideousKojima 2y ago
      I actually love the original BSG. And the new one started out strong but the writers clearly didn't have a plan for where they wanted things to go despite the opening credits insisting the Cylons have a plan.
      - mixmastamyk 2y ago
        Agreed. Not to mention the original BSG was strangled in its crib for costing too much. Something a production in the aughts didn't have to worry much about.
- daneel_w 2y 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 );
  - SoftTalker 2y ago
    Well, obviously tabs should always be 8 spaces.
    - daneel_w 2y ago
      Not sure if you're joking since 8 makes the whole problem even worse :)
  - Asooka 2y 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.
    - daneel_w 2y ago
      With a large set of arguments broken down to multiple lines I prefer to keep them clear of the function name. with_long_func_names( this_scheme, looks_muddled ); long_func_name( tidier, scheme ); But my main gripe with tabs is that no one agrees on the width.
      - mcdonje 2y ago
        Not agreeing on width is an argument in favor of tabs.
      - jdrek1 2y ago
- ooterness 2y ago
  To make more money: https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/ https://stackoverflow.blog/2017/06/15/developers-use-spaces-...
  - zahlman 2y 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-curious 2y ago
  https://youtu.be/oRva7UxGQDw?si=XUvMWQqIF-Uy1gNp https://youtu.be/oRva7UxGQDw?si=XUvMWQqIF-Uy1gNp
- rascul 2y ago
  This is the discussion I came here for.
- mcdonje 2y 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 2y 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.
    - smrq 2y ago
      Forcing a single opinionated tab width is an accessibility issue -- a real one, not a weird heuristic that boils down to "tab fans can't format". I've read multiple accounts from people who need either very small tab widths (to accommodate unusually large font sizes for eyesight reasons without cascading off the side of the screen), or very large tab widths (to accommodate difficulty in seeing indentation differences, again for eyesight reasons).
    - umbra07 2y ago
      I'm confused. how does handing control of the reading experience over to the reader = accessibility issue? isn't it the other way around? accessibility issues come in many different forms, and you can't accommodate them all yourself.
      - thfuran 1y ago
        Well, you see, it's too accessible, and that's a problem. Or something.
- Defletter 2y 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 2y ago
  Tabs are a control character and have no business being in a text file. Do you use ascii record separator characters too?
  - DidYaWipe 1y ago
    What an absurd statement.
  - IvyMike 2y ago
    Galaxy brain: indent using U+001F Unit Separator
  - imiric 2y ago
    No, but I do use Line Feed and Carriage Return.
  - yjftsjthsd-h 2y 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.
mmastrac 2y 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.
- joshstrange 2y ago
  `.git-blame-ignore-revs` is probably what you are looking for Example: https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa98b9e279175f2 https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...
  - y-curious 2y 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
- js2 2y ago
  It does. See `--ignore-revs-file`: https://git-scm.com/docs/git-blame 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/using-files/viewing-and-understanding-files#ignore-commits-in-the-blame-view 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%20for%20blame https://www.google.com/search?hl=en&q=git%20skip%20commit%20...
  - mmastrac 2y 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/ 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/ https://xkcd.com/1053/
joshstrange 2y 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 2y 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).
  - deleted 2y ago
    [deleted]
  - _Algernon_ 2y ago
    >Or just rewrite the whole history to have used spaces. Ah, yes. The 1984 approach to coding
- woodrowbarlow 2y ago
  `git blame -w` ignores whitespace-only changes, for what it's worth.
- radlad 2y ago
  Added to Git in 2019: https://github.com/git/git/commit/209f0755934a0c9b448408f9b7c9849c15041ecc https://github.com/git/git/commit/209f0755934a0c9b448408f9b7... Supported on Github in 2022: https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/ https://github.blog/changelog/2022-03-24-ignore-commits-in-t...
gwbas1c 2y 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.)
- diggan 2y ago
  FWIW: EditorConfig isn't a ".net ecosystem" thing but works across a ton of languages, editors and IDEs: https://editorconfig.org/ 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 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.
  - gwbas1c 2y 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.
    - diggan 2y ago
      > CI enforcement makes sure that everyone follows the rules, even if they "forget" to set up the git hook. Yeah, my wording was a bit poor (shouldn't have said "rather"), both are needed, one just helps you fix stuff faster :) And if you write your hook in a language that can cross-compile and can easily deal with multiple platforms (Go, Rust, NodeJS, many options [probably .net too?]), it's really easy. Just need to make the setup of them part of the onboarding.
gwbas1c 2y 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 2y 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.
gwbas1c 2y 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 2y 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 2y ago
what is this furry tomfoolory
user9999999999 2y 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 2y ago
Note that some files will need tabs such as Gopher menus and Makefile.
rurban 1y 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.

48 points by keybored 2y ago

Alifatisk 2y ago

Why would you want to convert from tabs to spaces?

diggan 2y 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 :)
- Alifatisk 2y ago
  I agree.
- gwbas1c 2y 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.
  - diggan 2y ago
    > I would always use the IDE's default and "not care" as long as the code was consistent. I mean, "just use the IDE's default" isn't really agreeing, unless that's what your entire organization does too, and you all use the same IDE :)
    - gwbas1c 1y ago
      Pretty much everywhere I've worked everyone uses the same IDE. When someone doesn't, we make sure they know we aren't going to make too many accommodations for them.
      - diggan 1y ago
        > Pretty much everywhere I've worked everyone uses the same IDE. FWIW, none of the places where I've worked has everyone used the same IDE (or an IDE at all, personally I use nvim so :shrug: ). Fun how the world is different for everyone :)
  - InsideOutSanta 2y ago
    > The problem with tabs is that they render as different widths in different contexts The funny thing is that this is why I prefer them. It means I control how indents render rather than the person who wrote the code.
    - mabster 2y ago
      I would agree, except that only deals with the left hand side of the code. We are also making decisions on the right hand side of the code to deal with lime width as well which only really works if all developers have the same tab size. Nowadays I just chuck format on save on all the code I deal with so I don't have to deal with any of this stuff anymore. If we take this to its longer conclusion though, it would be pretty good if our tooling supporting a difference between the view (using your own preferences) and storage (consistent code for committing to git or whatever).
      - DidYaWipe 1y ago
        What? If you have lines that are too wide, you can 1. Change the tab width in your IDE 2. Turn on line-wrapping
        mabster 1y ago
        1. This problem is introduced by increasing the tab width, so this solution is basically "don't do that". 2. Line wrapping on something like C where you have braces is okay, but not with something like Python where the code now looks wrong. I'm in the spaces camp, but I was musing about this for the tabs camp because wanting to adjust the indentation seems reasonable. (My "favourite" convention was Luajit where the convention was: 2 spaces, until we got to 8 spaces, in which case tab.)
        DidYaWipe 1y ago
        Yep, that's why line-wrapping is #2. I can see why it'd be less acceptable for some languages.
  - DidYaWipe 1y ago
    This is an oft-repeated and utterly bogus argument. You can simply change how many spaces a tab is in your own IDE. And in decades of programming in IDEs from Borland to Visual C++ (since there were separate 16- and 32-bit versions) to Xcode... I've never seen one default to five spaces. Four spaces is, by far, the most common. People who don't understand tabs are akin to those who don't understand styles: Doomed to laboriously dick around with formatting, and make work for everyone else.
  - motorest 1y 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 is that everyone touching the project can and often does have different defaults. If you work on a professional setting, specially in legacy projects, you are bound to touch files where your changes comprise mainly of whitespace changes.
    - gwbas1c 1y ago
      That's why "clean up tabbing" projects happen.
  - ujkiolp 1y ago
    [flagged]
  - deleted 1y ago
    [deleted]
mmastrac 2y 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 2y ago
  There's a debate about new BSG being better than old BSG?
  - mmastrac 2y ago
    I posit: For every topic of A vs B where A and B are related in some way, no matter how small, there exists an argument C where two people take increasingly opposed positions about which is better.
  - HideousKojima 2y ago
    I actually love the original BSG. And the new one started out strong but the writers clearly didn't have a plan for where they wanted things to go despite the opening credits insisting the Cylons have a plan.
    - mixmastamyk 2y ago
      Agreed. Not to mention the original BSG was strangled in its crib for costing too much. Something a production in the aughts didn't have to worry much about.
daneel_w 2y 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 );
- SoftTalker 2y ago
  Well, obviously tabs should always be 8 spaces.
  - daneel_w 2y ago
    Not sure if you're joking since 8 makes the whole problem even worse :)
- Asooka 2y 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.
  - daneel_w 2y ago
    With a large set of arguments broken down to multiple lines I prefer to keep them clear of the function name. with_long_func_names( this_scheme, looks_muddled ); long_func_name( tidier, scheme ); But my main gripe with tabs is that no one agrees on the width.
    - mcdonje 2y ago
      Not agreeing on width is an argument in favor of tabs.
    - jdrek1 2y ago
ooterness 2y ago
To make more money: https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/ https://stackoverflow.blog/2017/06/15/developers-use-spaces-...
- zahlman 2y 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-curious 2y ago
https://youtu.be/oRva7UxGQDw?si=XUvMWQqIF-Uy1gNp https://youtu.be/oRva7UxGQDw?si=XUvMWQqIF-Uy1gNp
rascul 2y ago
This is the discussion I came here for.
mcdonje 2y 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 2y 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.
  - smrq 2y ago
    Forcing a single opinionated tab width is an accessibility issue -- a real one, not a weird heuristic that boils down to "tab fans can't format". I've read multiple accounts from people who need either very small tab widths (to accommodate unusually large font sizes for eyesight reasons without cascading off the side of the screen), or very large tab widths (to accommodate difficulty in seeing indentation differences, again for eyesight reasons).
  - umbra07 2y ago
    I'm confused. how does handing control of the reading experience over to the reader = accessibility issue? isn't it the other way around? accessibility issues come in many different forms, and you can't accommodate them all yourself.
    - thfuran 1y ago
      Well, you see, it's too accessible, and that's a problem. Or something.
Defletter 2y 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 2y ago
Tabs are a control character and have no business being in a text file. Do you use ascii record separator characters too?
- DidYaWipe 1y ago
  What an absurd statement.
- IvyMike 2y ago
  Galaxy brain: indent using U+001F Unit Separator
- imiric 2y ago
  No, but I do use Line Feed and Carriage Return.
- yjftsjthsd-h 2y 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.

mmastrac 2y 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.

joshstrange 2y ago
`.git-blame-ignore-revs` is probably what you are looking for Example: https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa98b9e279175f2 https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...
- y-curious 2y 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
js2 2y ago
It does. See `--ignore-revs-file`: https://git-scm.com/docs/git-blame 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/using-files/viewing-and-understanding-files#ignore-commits-in-the-blame-view 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%20for%20blame https://www.google.com/search?hl=en&q=git%20skip%20commit%20...
- mmastrac 2y 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/ 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/ https://xkcd.com/1053/

joshstrange 2y 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 2y 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).
- deleted 2y ago
  [deleted]
- _Algernon_ 2y ago
  >Or just rewrite the whole history to have used spaces. Ah, yes. The 1984 approach to coding
woodrowbarlow 2y ago
`git blame -w` ignores whitespace-only changes, for what it's worth.
radlad 2y ago
Added to Git in 2019: https://github.com/git/git/commit/209f0755934a0c9b448408f9b7c9849c15041ecc https://github.com/git/git/commit/209f0755934a0c9b448408f9b7... Supported on Github in 2022: https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/ https://github.blog/changelog/2022-03-24-ignore-commits-in-t...

gwbas1c 2y 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.)

diggan 2y ago
FWIW: EditorConfig isn't a ".net ecosystem" thing but works across a ton of languages, editors and IDEs: https://editorconfig.org/ 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 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.
- gwbas1c 2y 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.
  - diggan 2y ago
    > CI enforcement makes sure that everyone follows the rules, even if they "forget" to set up the git hook. Yeah, my wording was a bit poor (shouldn't have said "rather"), both are needed, one just helps you fix stuff faster :) And if you write your hook in a language that can cross-compile and can easily deal with multiple platforms (Go, Rust, NodeJS, many options [probably .net too?]), it's really easy. Just need to make the setup of them part of the onboarding.

gwbas1c 2y 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 2y 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.

gwbas1c 2y 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 2y 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 2y ago

what is this furry tomfoolory

user9999999999 2y 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 2y ago

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

rurban 1y 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.