Re: [Monotone-devel] Re: [Monotone-commits-diffs] Revision 33eb2173fe9b55da6b26464380c68b8c02638a68

[Ralf S. Engelschall]

On Wed, Oct 31, 2007, Nathaniel Smith wrote:

> On Wed, Oct 31, 2007 at 05:04:15PM +0100, Ralf S. Engelschall wrote:
> > On Wed, Oct 31, 2007, address@hidden wrote:
> >
> > > * cmd_diff_log.cc (print_indented_set): Replace the empty string printed
> > >   for the project root with a single dot.
> > > * tests/merge_into_workspace: Fix test accordingly.
> >
> > Thanks. Can you also apply something similar to the output of mtn stat"?
> > There one has a similar nice output like "attr on \n" instead of "attr
> > on ."
>
> It's more confusing on stat, since stat can be called from
> subdirectories of the root... of course, it always gives paths
> relative to the root anyway, so at least it would still be consistent.
>
> My suggestion for this has been to have a uniform function for
> formatting paths for user display (in log, stat, etc.), that would
> look like:
>    file_path("foo") -> "'foo'"
>    file_path("foo bar") -> "'foo bar'"
>    file_path("") -> "'' (the root directory)"
> (The uniform function part is probably more important than the exact
> output, because the output is easy to tweak once it's been centralized
> to one point in the code.)

I'm +1 for first using a formatting function for all path outputs. Once
this function is in place we, second, can try to reach consensus on what
the best output is for the particular case of the root directory.

I personally tend towards:

   file_path("foo")          -> foo
   file_path("foo/bar")      -> foo/bar
   file_path("foo bar/quux") -> "foo bar/quux"
   file_path("")             -> ""

For the regular cases (no whitespaces contained and not the root
directory) this would be backward compatible to the current outputs and
for the special cases (whitespaces contained or the root directory) this
output is at least something most people understand as it is the way
they would enter (or copy & paste) it into a shell, too. Always quoting
paths certainly is fully consistent but might make the outputs perhaps
less readonable in general.
                                       Ralf S. Engelschall
                                       address@hidden
                                       www.engelschall.com