paths are always from root of branch

[Erik Bågfors]

bzr status and other commands always gives the path from the root of the branch, which is confusing because you get a file in the list, but you cannot run commands on that file.

Example:

User is in $bzrroot/foo

$ bzr status
modified:
 foo/foo1
 bar/bar1

$ bzr diff foo/foo1 <-- this will not work since user is already in directory "foo"

Proposed sollution: paths are always relative to cwd.

$ bzr status
modified:
 foo1
 ../bar/bar1

[Martin Pool (mbp)]

I agree

[Martin Pool (mbp)]

----- 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

[John O'Brien (jdobrien)]

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.

[John A Meinel (jameinel)]

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).

[John O'Brien (jdobrien)]

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.

[Parth Malwankar (parthm)]

Setting priority to medium due to the number of dups.

[Parth Malwankar (parthm)]

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.

[Russ Brown (pickscrape)]

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.

[Russ Brown (pickscrape)]

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.

[Martin Pool (mbp)]

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.

[Jelmer Vernooij (jelmer)]

This becomes even more important with nested trees.