When the user cd's to a sub-directory of a project, `darcs whatsnew'
still reports path names relative to the repository root. This makes it
difficult to directly use them via copy-and-paste (e.g. for a subsequent
`darcs add').

I suggest to add an option (e.g. --relative-filenames) that changes this
to reporting all path names relative to the current working directory.

Most likely, this option should be off by default, in the interest of
existing scripts and of users who tend to have similarly named files in
different directories.

Git has the requested behaviour by default, but has an option
(status.relativePaths) that you can set to `false' to switch to
`absolute' paths.

An example:
  mkdir -p top/sub
  cd top; darcs init; ls > top.lst
  cd sub; ls > sub.lst
  darcs whatsnew -ls
Currently, the output is
  a ./top.lst
  a ./sub/sub.lst
  a ./sub/
Desired output would be
  a ../top.lst
  a sub.lst
  a ./

Ben Franksen asked to be listed as a supporter of this feature.

1. What problem does the proposed feature solve?

It streamlines workflows where the user doesn't (temporarily) care where
the cwd is relative to the repository root.
It makes the output from `darcs whatsnew' consistent with the input for
`darcs add' or `darcs record', thus allowing quick copy-and-paste adding
of files and patches.

It also brings more consistent behaviour in the sense that
  darcs whatsnew .
or
  darcs whatsnew my/relative/path
currently still reports paths relative to the repository root, unlike
other unix tools like `find'.

2. Who are the stakeholders? Who is going to benefit/be affected by this
feature?
End-users

3. Who are the users?
All end-users.

4. What are the user scenarios?
An example:
  mkdir -p top/sub
  cd top; darcs init; ls > top.lst
  cd sub; ls > sub.lst
  darcs whatsnew -ls
Currently, the output is
  a ./top.lst
  a ./sub/sub.lst
  a ./sub/
Desired output would be
  a ../top.lst
  a sub.lst
  a ./

5. Does this change any pre-existing workflows? Does this introduce any
incompatibilities?
Only if it becomes the default.

6. Is the UI for this feature really Darcs-ish?
It is just one additional option that I would enable in my
.darcs/defaults -- looks sufficiently darcsish to me.

7. What are the possible unintended interactions with other pre-existing
features?
None, unless this becomes the default.

8. What are the alternative approaches to solving the same problem? Why
do we prefer this one?
There are alternative workflows that won't benefit from this feature:
- Use `darcs add -l'
  This is not very helpful if there are many unadded files and you just
want to add a few of them.
- Always work from the repository root
  May be a good idea sometimes, but is not practical in many cases (e.g.
when you need to compile in a subdirectory, but don't want to have a
Makefile in the repository root).