"bzr commit" should offer --targets like svn(1)

[Elliott Hughes]

i'm the main author of a GUI for multiple SCM systems (http://software.jessies.org/scm/) and i'm currently working on adding Bazaar support. i'm impressed by the combination of BitKeeper-like functionality with a CVS/Subversion-like interface, and had commit support working in minutes. you're missing one of Subversion's improvements over CVS, though, which is that you can give a file containing files to commit one per line rather than having to give them all on the command line. it's the --targets option below:

hydrogen:~$ svn commit -h
commit (ci): Send changes from your working copy to the repository.
usage: commit [PATH...]

  A log message must be provided, but it can be empty. If it is not
  given by a --message or --file option, an editor will be started.

Valid options:
  -m [--message] arg : specify commit message ARG
  -F [--file] arg : read data from file ARG
  -q [--quiet] : print as little as possible
  -N [--non-recursive] : operate on single directory only
  --targets arg : pass contents of file ARG as additional args
  --force-log : force validity of log message source
  --username arg : specify a username ARG
  --password arg : specify a password ARG
  --no-auth-cache : do not cache authentication tokens
  --non-interactive : do no interactive prompting
  --editor-cmd arg : use ARG as external editor
  --encoding arg : treat value as being in charset encoding ARG
  --config-dir arg : read user configuration files from directory ARG

(i'd also mention that i find bzr(1) help output better-worded. there's a lot of vagueness and ambiguity in the svn(1) help output, so don't imitate that!)

i know you're probably thinking "who needs to commit more files than their OS will accept as command-line arguments?", but my GUI front-end didn't always support this feature (available in svn(1) and bk(1) but not cvs(1)) and i actually had bug reports from people who ended up with partial checkins because some arguments were silently dropped. so it does seem to happen that end-users want to check in lots of files, and from my position in the middle, it's nice to know that one mechanism (--targets) will always do the right thing. (SCM is perfectly happy letting you commit 2000 files in one revision, and leaving 2 others uncommitted, if that's your decision.

we could add a work-around to SCM for the most common "lots of files" situation where you do actually want to check everything in (because you've done a global find/replace across lots of files but don't have any other changes and want to get the rename checked in before doing any more work), but the right solution is to add --targets to bzr(1).

[Martin Pool (mbp)]

Agree it would be useful; should require a small change in cmd_commit

This should probably be generalized to many commands that take a list of filenames - add, rm, diff, etc?

[Elliott Hughes (enh)]

> This should probably be generalized...

if it's easy. due to limitations in other version control systems, i already "add" each file individually (since they all get wrapped up in the next commit, it doesn't make any difference that they're not done as a group).

"rm" is sufficiently rare that we don't yet have an interface for it (unlike "revert").

"diff" probably isn't too useful, with the exception of the "all the files in the given revision" case. that seems to be useful enough that GUI front-ends end up implementing it themselves, and the more command-line oriented users write little scripts to turn a revision into a patch.

what i thought was interesting about the svn(1) commit help was the suggestion that --targets passes the contents of the given file as additional arguments; what it really means is that --targets adds the contents of the given file to the list of files to be committed. the implied functionality (as opposed to what they actually implemented) might be an interesting way to offer a generalized ability to deal with lots of arguments, whatever they are: pathnames, revisions, or anything else.

even with generalized functionality, the specific addition "--targets" sounds like a good idea to me; one of the best things about Bazaar compared to other distributed revision control systems in my opinion is how well it manages to look and feel like a member of the CVS family. i'm sure you're well aware how easily otherwise sensible people are scared by distributed revision control ;-)