monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: .mt-ignore and .cvsignore files


From: Bruno Hertz
Subject: [Monotone-devel] Re: .mt-ignore and .cvsignore files
Date: Wed, 18 May 2005 19:44:07 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux)

Nathaniel Smith <address@hidden> writes:

> On Tue, May 17, 2005 at 08:00:45PM +0200, Bruno Hertz wrote:
>> > Yes, but just because there's a subtle technical difference doesn't
>> > mean that people don't expect them to work the same, and won't
>> > make mistakes, experience confusion, etc. if they don't...
>> 
>> I think it's safe to assume your users have a basic knowledge of shell
>> expansion. E.g. the same applies to find . -name * vs. find . -name "*",
>> which people still have to somehow understand.
>> 
>> >
>> > Also, the difference here is in the other direction -- "*" would
>> > potentially include lots of things that _aren't_ included by ".".
>> > Which really is a bit surprising, no?
>> 
>> No. That's the feature you were talking about. Just document it.
>
> Maybe we're getting our wires crossed here, because I have no idea
> what you mean here :-).
>
> I can say that making "add ." and "add *" different for directories
> that don't have any dotfiles in them would confuse _me_, and I consider
> myself a rather savvy user...

Where's the confusion? '.' is a directory, so "add ." means feed a
directory to monotone and have it processed according to monotone
directory processing semantics. '*' on the other hand is subject to
shell expansion, and results into a list of files and directories. So
"add *" means feed a list of files and dirs to monotone and process
those objects according to respective semantics.

Now, if directory processing semantics means 'recurse and obey ignore
rules' whereas file processing semantics means 'do what requested on
the file and don't obey ignore rules', as long as this is documented
I see little room for confusion.

My find example btw was meant to illustrate exactly that point,
i.e. in

  find . -name "*"

the "*" is processed by find according to it's semantics, whatever
that may be. On the other hand, in

  find . -name *

the * is processed by the shell first, giving a presumably totally
different result.

As I see it, all of the above are standard situations pretty much
every user has to deal with on a regular basis.

And regarding the 'feature you meant', that was what you were
targeting at, right? Override ignore rules by direct file
specification.

Regards, Bruno.






reply via email to

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