mercurialtortoisehghgignorehgrc

Untracking files without them being deleted from yours AND OTHERS' file system?


I used hg forget <files> to untrack some files without them being deleted from my file system like using hg rm <files> does. I committed the change and running hg status listed these files as being untracked ? <files> as expected. I then pushed the changeset to our remote repository, someone else pulled and updated, and mercurial deleted these files from their file system!

Why doesn't Mercurial recognize these these files as being untracked with hg forget on someone else's copy of the repository the same way it does in the copy the changes originated?

Is their another way of untracking files without them being deleted from anybody's file system?


Solution

  • Both Git and Mercurial have the same issue here: You have some commit O (an old one) in which there is a file F. Now you update from O to new commit N, which says "there is no file F".

    What should the version control system do? Well, that depends on why F was removed, doesn't it? If we removed F because it was used before, but is now useless clutter, it should be removed.

    So, why is removing no-longer-used correct but keeping accidentally-committed also correct? And how should the VCS know which of these two is meant, given that all it can see is that commit O has both no-longer-used and accidentally-committed, while commit N has neither file?

    (Neither Git nor Mercurial have a good answer to this, as far as I know.)