[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: on the semantics of 'mtn mv'
From: |
Koen Kooi |
Subject: |
[Monotone-devel] Re: on the semantics of 'mtn mv' |
Date: |
Thu, 26 Jul 2007 09:59:28 +0200 |
User-agent: |
Thunderbird 2.0.0.5 (Macintosh/20070716) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathaniel Smith schreef:
> On Thu, Jul 26, 2007 at 09:18:32AM +1000, William Uther wrote:
>> I agree that things seems inconsistent given that example. I'm not
>> sure if we want case 1 to behave like case 2; I'd go with the other
>> way around. I'm not sure I like this 'magic add' semantics (but I'm
>> not horribly opposed to it either). Case 4 should return a user error.
>
> I know I'm usually the one haranguing against magic, but I'm actually
> pro- magic add. The reason being, in this case the user's intentions
> are totally clear to the program, and the program's results are quite
> obvious to the user.
what about this:
mkdir foo
touch foo/x foo/y
mtn add foo -R
mtn commit foo/x
<error about directory foo>
mtn commit foo #(includes foo/y which I don't want in _yet_)
Right now I have to commit either something broken (file x and file y) or
remove my work
in progress (file y) to commit file x. And not adding file y makes using mtn
diff a lot
harder.
When there are only 2 files I could use --exclude, but that gets tedious when
you have
lots of files and only want to commit a subset.
So, can the behaviour of commit be changes to commit 'recursively', i.e commit
foo/y won't
complain about directory foo, but add both the dir and the file?
regards,
Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFGqFRgMkyGM64RGpERArwAAJ0arKuuvC2t9ajKtX7WCn3ofkNkHwCfQGEi
rFH2ZEFyhmkyTnV91MG6QTI=
=tIWh
-----END PGP SIGNATURE-----