[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] relative paths from list commands
From: |
Thomas Moschny |
Subject: |
Re: [Monotone-devel] relative paths from list commands |
Date: |
Thu, 6 Jul 2006 11:27:20 +0200 |
User-agent: |
KMail/1.9.3 |
On Thursday 06 July 2006 05:39, Derek Scherger wrote:
> It seems rather odd to me (and some other folks on this list I believe)
> that, when run from within a subdirectory of the workspace, the ls
> commands list paths relative to the workspace root, rather than relative
> to the current directory.
>
> I'd be happy to change the various ls commands to print $PWD relative
> paths rather than workspace relative paths, if there's some general
> consensus that this would be a Good Thing.
+1 (but see below)
The zsh completion (and also that for other shells, I think) would benefit
from that, *especially* because there is currently no mtn command to find out
what the workspace root is.
Regarding consistency:
- The optional (and a bit undocumented) file inclusion pattern to the
'mtn ls {known|unknown|ignored|missing|changed}' commands must be
specified relative to the cwd. So we already have an inconsistency here.
- On the other hand, commands like 'mtn status', 'mtn update', and so on
also print 'absolute' paths. Shouldn't we change that, too?
- There is a serious ui problem wrt 'mtn commit'. When issued from within a
subdirectory and w/o args, it happily commits all changes from the whole
working directory. This is the reason why 'mtn ls {known|changed}' list
(a) all files and (b) with their 'absolute' paths: They serve sort of a
--dry-run for the commit. We should preserve this functionality.
So the obvious suggestion would be to add a --relative option in order to
switch to output of relative paths only for those that are prepared to deal
with paths like '../ChangeLog' for some 'mtn ls' command.
Thomas
--
Thomas Moschny <address@hidden>