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