[pqm-submit:MERGE] Remove default --message

[James Henstridge]

On 18/03/2008, John Arbash Meinel <john at arbash-meinel.com> wrote:
>  > That does seem like a bug.  So you're changing it to do open() rather
>  > than open_containing() if a path is provided?
>  >
>
>
> Well, it already had a check for "if relpath and not tree", I just
>  changed it to "if relpath and not tree and location != '.'".
>
>  I believe what people want is the ability to be in a subdir and do "bzr
>  pqm-submit". I'm fine with that. What we are turning off is any case of
>  "bzr pqm-submit 'foo'" that doesn't directly refer to a branch.

Right.  With no argument, I'd expect the command to act on a the
current branch (so do open_containing('.')).  If I pass a branch
location though, I'd expect it to do open(location) instead.

This seems to be the heuristic that "bzr check" uses, but it does not
seem consistent between commands :(


>  So... effectively plain .open() but I just worked it into the way we are
>  doing it now.
>
>  It is a bit complex because we want to open a working tree if it is
>  available so that we can check it is clean. The way I would usually do
>  that is:

Did you mean to write something extra here?

>
>
>  >
>  >>  I didn't want to push this automatically without telling people, because
>  >>  it does disallow 'bzr pqm-submit' with no -m/--message.
>  >
>  > I'd say go ahead and do it.  If there are complaints, we could add an
>  > option to use the last commit as the merge message (which users could
>  > turn on by default with an alias if they want the old behaviour).
>  >
>  > James.
>  >
>
>
> Well, Ian Clatworthy has mentioned that he does use the last commit
>  message. I'll follow up with him a bit, because atm, I think that is
>  actually incorrect workflow. (Since it won't attribute the merge to him,
>  etc.)

Fair enough.

James.