monotone-devel
[Top][All Lists]
Advanced

[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-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]