All commands should accept an explicit location or -d

[Maciej Katafiasz]

Every command should accept either an explicit location or -d for every repository it uses. Ie. for bzr missing, I should be able to give two remote branches and have it generate a report. That's currently impossible (bug #207762). The ability to operate on branches I haven't cloned to my disk is a killer feature and I'd consider switching to bzr for just that. It's invaluable when I need to find a specific change in a forest of branches I don't know, or when trying to determine which branch I should be cloning, etc.

Ideally, the whole thing should happen completely automatically whenever any command needs to accept a branch. If that's not possible, making it easier to support it than not and going over all commands and checking them for consistency would be a good replacement. And once it's done and working for all core and popular plugin commands, it should be added to http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html in bold letters.

[Martin Pool (mbp)]

I agree, that would be great. Want to try it?

[Maciej Katafiasz (mathrick)]

Depends on how hard you estimate that to be. If it's not too extensive a change, and I can get some guidance, then yes, I could try my hand at it.

[Martin Pool (mbp)]

On 26 February 2010 23:22, Maciej Katafiasz <email address hidden> wrote:
> Depends on how hard you estimate that to be. If it's not too extensive a
> change, and I can get some guidance, then yes, I could try my hand at
> it

The easiest way to do this would be to copy and paste the existing -d
implementation from the commands that have it to those that don't. A
patch to do this would be acceptable, but as you note it would be more
elegant to do this globally.

To do that you probably need to add -d as a global option, and then
have a concept on the "Command" class of the default location. Code
that currently relies on getcwd should use this instead.

--
Martin <http://launchpad.net/~mbp/>

[Colin D Bennett (colinb)]

The following table summarizes the Bazaar commands that are missing support for
the -d / --directory option to override the current working directory (CWD).
Support for the --directory option is required for user interface consistency,
but more importantly there are operations that are impossible to perform on a
remote repository since a remote branch can never be the CWD.

Therefore, support for --directory is less critical for commands operate on a
checkout or working tree since it is possible to use them by simply changing
working directories.

On the other hand, some commands can operate on a branch without a working tree
and so may logically be used on a remote repository (which cannot be the
current working directory). For such commands, the --directory option is
required to be able to operate on remote branches.

Legend:

Command - command name
Has -d? - does the command support the -d / --directory option (y/n/-)
           'y' means it supports it
           'n' means it does not, but it should
           '-' means it is not needed
Branch? - can the command work on a branch without a working tree? (y/n)
Comment - comments on the reasoning

                Has Branch?
Command -d? Comment
--------------- ---- ------- ------------------------------------------------
add - n FILE... argument overrides CWD
alias - n FILENAME argument overrides CWD
alias - n Does not refer to a file or branch
annotate - y FILENAME argument overrides CWD
bind - n Operates on a checkout
branch - y Two arguments specify both branches
break-lock - y LOCATION argument gives the branch
cat - y FILENAME argument gives the branch
check - y PATH argument gives the branch
checkout - n BRANCH_LOCATION / TO_LOCATION are branch/checkout
clean-tree - n Operates on working tree only
commit - y SELECTED... argument overrides CWD
conflicts - n Operates on working tree only
deleted - n Operates on working tree only
diff - y Branches given by --new, --old, or FILE...
export - y BRANCH_OR_SUBDIR argument overrides CWD
help - n Just displays help
ignore - n Operates on working tree only
ignored - n Operates on working tree only
info - y LOCATION argument overrides CWD
init - y LOCATION argument overrides CWD
init-repository - y LOCATION argument overrides CWD
join ? ? Don't know if it can work without working tree
log - y FILE... argument overrides CWD
ls - y PATH argument overrides CWD
merge - n Operates on working tree only
missing n y Can operate on two branches
mkdir - n Operates on working tree only
mv - n Operates on working tree only
nick n y Can operate on a branch
pack n y BRANCH_OR_REP...

[Colin D Bennett (colinb)]

^^^ Sorry, Launchpad really messed up the formatting by collapsing multiple spaces to a single space and wrapping the lines, etc.

(Launchpad should at least have a Preview button before posting a comment, if not an Edit button to fix comments after posting.)

See <http://gibibit.com/Bazaar_-d_option_support_list.txt>.

[Andrew Bennetts (spiv)]

Wow, that's great. Thanks, Colin!

(FWIW, the formatting was preserved in the email version of your comment.)

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:
> Wow, that's great. Thanks, Colin!
>
> (FWIW, the formatting was preserved in the email version of your
> comment.)
>

Technically, launchpad preserves the text, if you look at the HTML,
you'll see the extra spaces. However Launchpad *only* turns leading
whitespace into &nbsp; which means that internal whitespace gets
flattened by HTML renderers.

Anyway, as such a future update to Launchpad *could* change the views to
set the html chars. I'm pretty sure the data is fine in the DB.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkukXokACgkQJdeBCYSNAANZ5gCg1ccwvcR9Lj9k88oeaGv0xYKk
d6kAoNUOt+ND5K3Np1D3DG8U1ueZXSJ/
=vygT
-----END PGP SIGNATURE-----

[Martin Pool (mbp)]

On 20 March 2010 16:35, John A Meinel <email address hidden> wrote:
> Technically, launchpad preserves the text, if you look at the HTML,
> you'll see the extra spaces. However Launchpad *only* turns leading
> whitespace into &nbsp; which means that internal whitespace gets
> flattened by HTML renderers.
>
> Anyway, as such a future update to Launchpad *could* change the views to
> set the html chars. I'm pretty sure the data is fine in the DB.

That's correct. There's a bug asking for plain monospace comments at
least as an option.

--
Martin <http://launchpad.net/~mbp/>

[John A Meinel (jameinel)]

Can we get an update on the status of this? I'm going to close this bug since many commands did receive a -d option in this release. However, we may want to open a new bug for any remaining commands.