Previewing changes

[David Ingamells]

John Arbash Meinel wrote:
> So... there are a few things about merge --preview which should probably
> be explained.
>
> 1) When you do 'bzr merge', we stage all the changes into
> .bzr/checkout/limbo/*
>
> This allows us to find out about conflicts and run into any problems
> *before* we change any of your precious files.
>
> 2) The files and directories in limbo do not *look* like the ones in the
> tree. The generally have names like "new-1234". This happens because we
> have to avoid collisions in the staging area, and we aren't going to
> recreate the entire working tree each time.
>
> 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.)
>
> 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.
> Basically, if I was writing the quick-and-dirty solution, I would have
> to export the basis tree to a temp directory, and then export the
> preview tree to another temp directory, and then run your
> diff/meld/kdiff3 process on it (and for most tools, you would also want
> the "BASE" tree, which is the common ancestor between them.)
> It is possible, but it *really* wouldn't scale into large projects.
>
> 5) I don't know whether Tortoise/Olive/Qbzr yet play with the 'merge
> - --preview' functionality. Aaron has done a great job on the internals,
> and I would expect them to eventually grow support for it. (He's even
> been working on making PreviewTree layerable, so you can see what your
> merge would look like assuming this other merge would have occurred.)
>
> John
> =:->
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkiQc54ACgkQJdeBCYSNAAM0yACglztA9UMFb7C3FMj2vX86gr9v
> CjwAnjZllwLUAlfs+yXTX+dQI+8uzVyK
> =3DDW
> -----END PGP SIGNATURE-----
>
>   
If I may also stick my oar into this debate, the area of diffing merges 
is one that
my users complain about. If you have a patch file, the only ways I know 
of for doing a review of it are:

1) cat the merge file and look at the diff lines in it.
2) merge --preview, which really gives the same text as (1)
3) create your own branch (not checkout) merge the patch file and run 
diff on the branch.

Only option 3 gives the facility to run a visual diff tool, such as 
meld. But option 3 is heavy in terms of resource usage. This will drop a 
bit when stacked branches are possible, but will still be suboptimal (as 
has been said elsewhere in this thread).

All the information needed to produce a nice visual diff is available. 
It just needs the right code in diff to use that information.

One other point, diff also doesn't behave "right" with a new file. It 
should run the visual diff tool with an empty initial file instead of 
just doing a cat to stdout. (see the original correspondent's remark 
about using less)