Re: [Monotone-devel] non-recursive add considered harmful

[hendrik]

On Wed, Mar 14, 2007 at 02:59:48PM +1100, Daniel Carosone wrote:
> On Tue, Mar 13, 2007 at 10:23:25PM +0100, Markus Schiltknecht wrote:
> > I fail to see how this should be more user-friendly, more secure or
> > more consistent than a recursive by default behavior.
> 
> For those who missed the discussion on this subject during the summit,
> let me restate that while I do have opinions and preferences with
> regard to whether or not commands like 'add' should be recursive by
> default, the prime directive here should be consistency.

Yes.

> I expect
> that my personal preferences can and should be overridden in favour of
> overall consistency and "harmony of user experience".
> 
> From that perspective, I can't really see that we can ever
> consistently have non-recursive default behaviour.

Nor can I.

> 
> The killer example here is 'update'; we don't and likely never will
> support any kind of partial/restricted/non-recursive 'update'.
> Partial update is just not meaningful, in the context of a command
> that updates the base revision of a workspace[1] to reflect snapshots
> of the entire tree[2].

Even more so is rm ... Can you inagine deleting a directory without 
deleting the files in it?

> 
> If commands are to be consistent, they need to be consistent with a
> recursive, whole-of-tree update.  Commands like commit and add can
> (and do) sensibly take restrictions, but making them non-recursive
> seems like a rat-hole that gets deeper by the day.

Yes.

> 
> I've been hesitating to suggest it, but perhaps something to consider
> here for the 'add' and similar cases is a --interactive switch, that
> would operate like 'rm -i': prompting the user for 'yes/no/all/none'
> as each file is processed.

This would be useful ... eslecially if there's also a 'later' option 
that lets you defer a decision until you've seen the whole list.  If you 
say later, the file is put in a list that gets processed at the end.
Not sure how useful it would be in monotone, but there are times with 
rm and other commands that I would have appreciated such an option.

> If you said no to a directory, that directory and all its contents
> would be skipped.  If you wanted to add the dir, but not the contents,
> you could say 'yes' to the dir and 'none' for the first file inside.
> 
> It's a lazy workaround for clever shell globs or discrete commands
> with explicit lists, but it's proably better than making up some weird
> globlike metasyntax for "a directory but not its contents" that noone
> will remember to use or quote properly for their shell.  Without being
> too clever, it might significantly help user convenience and offer an
> opportunity to eliminate surprises.

-- hendrik