UI confusion / consistency

[Martin Pool]

> > Well, I agree about "ignore", but I think it should be equivalent to
> > "add".  For "conflicts", we can't seem to agree about "status" display,
> > so there's no point changing conflicts until then.
> >
> > Since we're a whole tree tool, I think we should show all changes.  But
> > others think we should only show changes encompassed by the cwd.  I
> > think that if your write operations are whole-tree, your read operations
> > should also be.

It seems like we all agree that paths should always be shown relative
to the cwd, so we can start on that regardless of the default scope of
commands.

> I think we could easily have commit assume a filter of '.'. That would
> allow status of '.' etc etc etc to be consistent.
>
> I agree that the default scope of operations should be the same across
> all commands.

Me too.

> My personal preference would be to have all operations work from cwd
> down, by default - even operations like merge could do this in principal
> with robust cherrypick suppport; that said today we're not there so
> perhaps erroring on commands that could be partial by default when we
> fix bugs would be sensible to avoid surprising people.
>
> OTOH what we have now works well and is pretty tasty (but I _very_
> rarely cd into a subdir on projects I work on).

I also normally either commit the whole tree, or just specific files.
I do sometimes work from one subdirectory.

I think you're right that merge and merge-like operations are the
sticking point.  For example, would you really want 'pull' in a
subdirectory to pull in only changes to that subdirectory?  Doing that
would require svn-like support for a different basis revision for each
file, and I'm not sure that's really desirable.

It would potentially be a surprising change when this happens, but not
insurmountable and that shouldn't put us off assessing what's really
best.

Possibly we're over-generalizing from revert, and we should just make
revert back up the discarded files...

We can also communicate more, by making more commands explain what
directory they're operating on, and what files are being affected.

-- 
Martin