Mercurial Digest, Vol 28, Issue 41

Giorgos Keramidas keramida at ceid.upatras.gr
Sat Aug 25 17:51:10 CDT 2007


On 2007-08-25 23:10, Brian Baker <brian_e_baker at yahoo.com> wrote:
> Due to working practices beyond my control I want to be able to use
> mercurial in a 'lightweight' way. I've got a big source tree with lots
> of files, and I want to version control just the ones that I edit.
> These files are spread fairly sparsely through the large tree, I add
> each file that I edit.
>
> hg add with no arguments adds everything
> there isn't an unadd command
> One typo and its a headache to tidy up.

The only tricky part with the above reasoning is that there *is* an
unadd command.  It is callled `revert'.

If you accidentally `add' many files, you can revert the files you don't
really want too add with:

    % hg stat -a > /tmp/flist.$$

edit `/tmp/flist.$$' to remove the files you *really* want to add, and
then do something like:

   % cut -c 3- /tmp/flist.$$ | xargs hg revert

This will `revert' the files to their previous `unadded' state, and you
are ready to continue with your work.

Other, more elaborate schemes are possible too, if you use the MQ
extension.  You can create a git-style patch with the stuff you *really*
want to commit, by carefully using the qrefresh -I and -X options:

    % hg qinit -c
    % hg qnew -f --git -I file1 file2 file3 patchname
    % hg qpop
    % hg revert --no-backup --all

This will `revert' the files you don't really want to commit.  Then, you
can manually edit the patch file in `.hg/patches/patchname', change its
log message and convert it to a `permanent' changeset with:

    % hg qpush
    % hg qdel -r tip

I'm not opposing your suggestion to make `hg add' more resilient to case
of fat-fingering, but it's not like the end of the world has come either.

- Giorgos



More information about the Mercurial mailing list