Previewing changes

[Ben Finney]

John Arbash Meinel <john at arbash-meinel.com> writes:

> So... there are a few things about merge --preview which should
> probably be explained.

Thanks.

> 1) When you do 'bzr merge', we stage all the changes into
> .bzr/checkout/limbo/*
[…]

> 2) The files and directories in limbo do not *look* like the ones in
> the tree.
[…]

> 3) 'merge --preview' generally works by staging the merge, and then
> presenting the combination of the basis-tree + staged changes as
> another tree "snapshot" which can then be compared to other trees
> (such as the original basis tree, which is what 'merge --preview'
> explicitly does.)

All of the above seem like problems analogous to what 'bzr diff' must
deal with when comparing revisions in remote branches (some of which
may not have working trees).

> 4) This is rather difficult to present to a 3rd party too. The basis
> tree doesn't exist on disk (it was the last commit to the working
> tree, which may be partial, or may have more uncommitted changes),
> and the temporary changed files do not have names which match the
> original path.

Is this the point at which 'bzr merge --preview' is doing something
that is impossible to pass to the existing 'bzr diff' functionality?

It seems that the 'bzr diff' interface and accessible functionality
has been improved so much in response to requests; it would be silly
to have an independent, less-functional implementation of the 'diff'
interface via 'merge', and the resulting "why can 'diff' do this but
'merge --preview' can't?" questions, if that could be avoided by
making use of the existing 'diff' and all its current and future
improvements.

Thanks for the discussion and explanation.

-- 
 \            “Why was I with her? She reminds me of you. In fact, she |
  `\                reminds me more of you than you do!” —Groucho Marx |
_o__)                                                                  |
Ben Finney