"bzr merge --pull" does not list changes

[Stefan Monnier]

Maybe this is a duplicate of bug #113990. When "merge --pull" does a pull, the command just says "All changes applied successfully." without showing the usual list of modifications applied.
This is problematic for some external tools that want to keep track of the state of each file.
The same holds for "uncommit".

[Dan Watkins (oddbloke)]

Hi Stefan,

Thanks for the bug report! We really shouldn't have this sort of inconsistency in the UI, so I'm confirming this bug. I don't consider it a duplicate of bug #113990, though it's in the same class of problems, as it is regarding a separate command.

Cheers,
Dan

[Robert Collins (lifeless)]

On Mon, 2008-03-17 at 13:01 +0000, Stefan Monnier wrote:
> Public bug reported:
>
> Maybe this is a duplicate of #113990. When "merge --pull" does a pull, the command just says "All changes applied successfully." without showing the usual list of modifications applied.
> This is problematic for some external tools that want to keep track of the state of each file.
> The same holds for "uncommit".

I agree this is a bug, but external tools should not be parsing the
command output to synchronise with bzr, because a use could trivially do
any operation without using your tool and thus desynchronise things.

We have a growing library of robust machine processable apis in the
xmloutput plugin, which will be getting moved into the core.

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Stefan Monnier (monnier)]

> I agree this is a bug, but external tools should not be parsing the
> command output to synchronise with bzr, because a use could trivially do
> any operation without using your tool and thus desynchronise things.

There might be better solutions in theory, but in my world, it's
a pretty good simple solution, whose limitations don't surprise users:
it's OK if doing something behind the tool's back leads to the tool
giving out out-of-date information, especially if the tool actually
checks his assumptions whenever it needs them.

> We have a growing library of robust machine processable apis in the
> xmloutput plugin, which will be getting moved into the core.

Plain text is much easier to parse than XML i the Emacs world, but an
XML format might be just fine.

This said, the format is not what's at stake: the issue is about making
sure that every command outputs (or can be made to output) the list of
changes it performed.

        Stefan