3 ms·

Sounds like a better idea to just change the secret.

• nkrisc 10y ago
  That is always the best course of action, no? Once it's out, assume it's compromised.
• tcfunk 10y ago
  Why not both? :)
  • tonybaroneee 10y ago
    That's time you could be spending on adding a new feature or fixing a bug :) Just change the secret and be done with it!
    • scaryclam 10y ago
      And when someone new thinks "that password's wrong, it'll update it!"? Do both, gets rid of the issue on both sides and really doesn't take long :)
      • gkya 10y ago
        Why would they if the tip does not have any passwords in it? It's not like a potential contributor will search the commit log to see if there were once passwords around. Besides, making such changes in public changesets is rude, to say the least.
        • scaryclam 10y ago
          What I mean is, lots of folks seem to be saying to ignore the presence of the file and just change the password where it's used. Removing the file, or the password and adding a comment, as well as changing the password where it's used is much less likely to end up with a re-added password later. Of course, removing the file, adding it to .gitignore and changing the password makes it even harder as a contributor would have to work to add the password back, which is even less likely to happen.
          • gkya 10y ago
            Oh sorry I tought you were saying to remove it from VCS history (as said many times in the thread). I totally agree you.
• SilasX 10y ago
  But then what do you do when you accidentally commit someone's private medical records or get a "right to be forgotten" order? Edit: I had similar objections to "why not rework databases as an immutable diff history?" https://news.ycombinator.com/item?id=13581096 https://news.ycombinator.com/item?id=13581096