paths are always from root of branch

I agree

----- Forwarded message from Alexander Belchenko <email address hidden> -----

From: Alexander Belchenko <email address hidden>
Subject: Question about diff output (diff in subdir)
Date: Wed, 01 Feb 2006 14:15:03 +0200
To: Bazaar-NG <email address hidden>

When I do bzr diff in subdir I've got output with filenames relative to
branch root. Is this good?

If I have following use case: some editor (e.g. FTE) has built-in
support for bzr commands by invoking bzr from command line and catching
its output. This editor is able to parse output of diff command and
provide click-n-jump feature, when I from diff could jump to appropriate
location in file. But unfortunately this editor don't know anything
about bzr root dir and the fact that all path is relative to that root.
So when I run bzr diff from subdir I have broken paths in output. And
editor could not jump to appropriate file from diff because path is broken.

Reproduction of problem:

>bzr init
>bzr mkdir dir
added dir
>cd dir
>echo spam > file.txt
>bzr add
added dir/file.txt
>bzr diff
=== added directory 'dir'
=== added file 'dir/file.txt'
--- /dev/null
+++ dir/file.txt
@@ -0,0 +1,1 @@
+spam

--
Alexander

----- End forwarded message -----
--
Martin

I noticed this bug had "Mentoring Avaialble" so I have started a branch to work on this bug.

I am assuming this is the way Mentoring is supposed to work. Please correct me if I'm wrong.

We're happy to help you work on this if you desire. Please either contact us at "<email address hidden>" or contact one of the developers directly for any assistance you might need.

I have the feeling you'll want to open a discussion on the mailing list first, as we want to make sure your general implementation idea fits with what we are thinking. (Rather than having you do the work, and then possibly need to change it).

Just an FYI, I am still interested in working on this, however I am currently on a large project for my 'day job' which is going to keep my busy for the next couple of months. I will be able to resume work on this toward the end of June.

If this becomes a higher priority, someone else may want to take it on.

Setting priority to medium due to the number of dups.

I am not sure if we should change the behavior of status, not because I think that the behavior is correct but because its been so long that many users may be used to it now like I am :)
Possibly as suggested in dup bug #520662 we could have an option for this to allow users to alias it if they want.

I think that both behaviours are desirable in different situations. Given the history of bzr always showing paths relative to the branch root, that should continue to be the default behaviour.

Given that, I'd say that an option would be ideal.

I think it would be helpful (in determining the size of this problem) to determine the commands that should grow an option to show paths relatively.

Obviously, "status" is the primary target, but essentially anything that outputs file paths could also be considered ("conflicts" being one that springs to mind).

What about commands like "update"? If I run an update, it lists the files affected. However, I think one distinction to make is that while "status" and "conflicts" produce repeatable output, "update" does not. Its output is more informational than being the purpose of the command itself.

So my thought is that we should be looking at commands that have the core purpose of outputting paths to files, and looking at adding an option to those. Commands that output paths to files as information about some larger task are out of scope I think.

I think there should be a standard command to print tree paths; that
can then be governed by a configuration variable, which can be set
from the command line for relevant commands.

This becomes even more important with nested trees.