8

I know that in Mercurial, "history is sacred".

But let's say someone accidentally commits something they shouldn't, like a settings file containing a password or something. Let's even say some time passes before anyone realizes it, so its been hanging around for several commits. Obviously, the discoverer then removes the sensitive data from the repository.

Is there any way to permanently scrub that file or the sensitive data from the commit history, as though it never existed? Or would that sensitive data just be a permanent part of the repo forever and ever?

Brian Lacy
  • 18,785
  • 10
  • 55
  • 73
  • 1
    dupe: http://stackoverflow.com/questions/1029480/is-there-a-way-to-remove-the-history-for-a-single-file-in-mercurial – Andy Arismendi Mar 24 '13 at 03:38
  • 2
    The answer given there is not very helpful. It's technically correct in a sense. But if you're willing to tell all of the people who might've cloned your repository to strip a change, you can remove the changeset that introduces the change, then use something like transplant to move all the changes after that over and give them new commit hashes. – Omnifarious Mar 24 '13 at 17:11
  • 1
    Martin Geisler's answer is a much better one, and is another method in addition to the one I suggested. – Omnifarious Mar 24 '13 at 17:12

4 Answers4

2

There are a few methods to accomplish this. All of them require the cooperation of everybody who has cloned your repository or pulled changesets from it after the change was introduced.

Which method to use depends on the exact nature of the committed data and where it is in the history. All of them require the use of Mercurial extensions and cannot be accomplished with core Mercurial. Luckily, all the required extensions are shipped by default with Mercurial and simply have to be enabled.

I'm not going into detail about the methods here as there are several answers that give different methods in the question this is a dupe of. I just want to be clear that the accepted answer in that question is technically correct, but not useful. It is actually possible.

Omnifarious
  • 54,333
  • 19
  • 131
  • 194
2

If, and only if, this repository hasn't escaped into the wild, you can remove a file from history by essentially cloning to a new repository while filtering the sensitive file in the process, using hg convert Hg Convert Extension doc here

Commonly, we find something when we audit the repository prior to publishing or delivering to a client, such as a web.config or ini file with a password.

The extension isn't enabled by default, but is included with all clients I use, you need to enable it before Mercurial will recognize the convert command.

If using Tortoise Hg or Kiln, for example:

  1. Open Tortoise Hg -> Global Settings -> Extensions
  2. Check the box beside "Convert"
  3. Click Ok

Or edit Mercurial.ini directly:

[extensions]
convert =

Go to the directory above your repository (in my example, my repos is HelloApp):

  1. Create a file named filemap.txt

  2. Add a line with the full path to the filename you want to exclude.

    exclude HelloApp/sensitive.config

  3. Open a command prompt, cd to the same directory, containing your filemap.txt, and run the hg convert

    cd C:\projects

hg convert --filemap filemap.txt HelloApp HelloApp_clean

  4. Then get latest working copy:

    cd HelloApp_clean
hg update

You will need to create a fresh clone on your server with your clean copy.

codenheim
  • 20,467
  • 1
  • 59
  • 80
1

I haven't investigated the details of how hooks work so this idea may not fully play out. It may be possible to set up hooks to disallow the committing, pushing and pulling of your sensitive files. There are hooks that will run before committing or pushing (precommit and preoutgoing). Protecting the hooks so they are not circumvented is another issue that Mercurial: The Definitive Guide also discusses.

Mark
  • 452
  • 2
  • 9
1

No. Not really. If you can convince everyone who had access to delete and reclone, you can remove the file from future access.

But if you, e.g., pushed your root password to a public Bitbucket repo - ? You should change it. Your information is now public and leaked and should be considered as such. Sorry.

Paul Nathan
  • 39,638
  • 28
  • 112
  • 212