On Mar 4, 2015, at 4:08 PM, David Mason <dma...@ryerson.ca> wrote: > > The only problem I > see with rm is that, at first blush (looking at the table):
You’re correct. If you try to remove an added but uncommitted new file, hg warns you: not removing foo: file has been marked for add (use forget to undo) hg forget isn’t just “forget uncommitted changes,” though, it’s more like “svn rm --keep-local”. That is, it removes the file from the repo, but leaves the local copy behind. > hg rm -f foo > is the way to remove a newly added file. It's good, as in safe, but > it wouldn't occur to me (because rm -f in the shell is so total). Yeah, that’s a bit of a strange design decision. I could argue either side of it, but I don’t really see a point in making Fossil pointlessly different from all other VCSes again. If we’re going to make it emulate something, we shouldn’t bury any little design change land mines in its implementation. > Actually, it turns > out that the right way to do it is: > hg forget foo Fossil, Mercurial, Bazaar and Subversion do the same thing with “revert”. Git, in its ever-strange way, does it with “git reset <file>” or “git rm --cached <file>”. I seem to recall that CVS made you move the just-added file out of the way, revert the tree, then move it back. Bleah. The reason hg has two ways to achieve the same end is that the two commands are semantically different, but just *happen* to achieve the same end. hg forget says, “Take this file out of the repo, but leave the local copy.” hg revert says, “Disregard my request to add this local file to the repo.” > So I would endorse the change to "fossil rm" if we added a "fossil > forget" command. fossil revert already provides this. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
