Major diff/merge changes in bzr and explorer

Andreas Sommer andreas.sommer87 at googlemail.com
Thu May 3 21:21:49 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

From: Aaron Bentley <aaron at aaronbentley.com>
Sent: 03.05.2012 16:07
To: bazaar at lists.canonical.com
Subject: Re: Major diff/merge changes in bzr and explorer
> On 12-05-03 04:41 AM, Andreas Sommer wrote:
>> From: Gordon Tyler <gordon at doxxx.net>
> 
>>> Another diff-related feature request that I recall seeing was
>>> for proper handling of multi-file diffs with tools that can
>>> handle them.
> 
>> Good point. There is an important distinction to make:
> 
>> 1) Tools that show multiple 2-way diffs, e.g. in tabs. This is
>> done by multiple process invocations (e.g. WinMerge) or passing
>> the file pairs as parameters (e.g. meld) as described in the bug
>> comments.
> 
>> 2) Tools that can handle 3+ way diffs like Diffuse. 'bzr diff'
>> can only compare two revisions at the moment, so multi-revision
>> diff tools can not be used yet. But it might be worth considering
>> it in the implementation of a common tool invocation module. For
>> example, instead of parameters (old_filename,new_filename) one
>> could use a list new_filenames (that would contain one filename
>> in case of the traditional 2-way diff).
> 
> I would distinguish between per-file diff tools and per-tree diff 
> tools.  The diff code I wrote handles per-file diff tools as 
> extra_factories for DiffTree.  I imagined that per-tree diff tools 
> would be implemented using the same API as DiffTree, and
> registered with bzrlib.diff.format_registry, but I didn't do any
> work on that.
> 
> Aaron

Not sure what you mean by per-tree diff tools - no tool except for the
bzr textual representation can display all different types of changes
(modified text files or pictures, symlinks, changed directories, renames).

I propose the following: Bazaar's textual representation remains the
default, and the differs in extra_factories are tried first. The
"--format" parameter which does the selection in
bzrlib.diff.format_registry, will only be valid for the internal diff
(e.g. one could implement different formats apart from the unified
diff, that's how I understand the word "format").
Now for the external tools: I will add an option like
"bzr.difftool.MyDiffTool.is_default" (true/false). Also an option
".is_console_based" that says whether it can be run without a
graphical environment. "bzr diff" without the "--tool" parameter will
try all "default" differs first before using the textual
representation (if there's no graphical environment like in an SSH
session (how would I check this??), only the ones with
.is_console_based==true). In contrast, "bzr diff --tool=MyCoolTool"
will select the tool with that name and use it for all changes that it
supports, else falls back to other preferred tools, then to built-in
diff. The ".is_default" option thus means that "bzr diff" uses them
automatically without the "--tool" parameter, so that a user can
replace the default diff algorithm completely by another tool.

Does that make sense somehow? Or how did you imagine this, also
regarding the existing DiffPath implementation?

Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJPovbsAAoJEPeCHX6zCCMvanAQAI0kJuflgfHxREAIpvx6Dstz
NoTAyNMiYmRCOic1J9pl0q4FaGM7K7doB5UY72zhXJv6itMTlL7nK+U2QQ+N8ojk
8ciCQQ1TRpeXbvGf2CCmHEdTnI2a8fIVVl/yT3ndDtTRDODYvfLaZBCP6Xe8Hc+J
msBuu8fsiJ8jCrtMl4dDQYAvDKnMXSPZV6Ms/kLDsWa50KI1LRZBLo4E1W913wAQ
NdLsLRUXQ4dyOERg5/sAU39O6Vhpy51DNyRZjM/X79Apmf77WXT1XB99yS17EYKc
mT47nEe0i3qoDT2VZ0Z0JwGsqplAwASbHCf+yHaGoqsXW2SocEBoBjzxekpePQzU
yADekltHywaH9fTZRdIJ3ub51/eCG/BS++IkFeT6P2xVmfzvE0duPBJyreuUVwoJ
Ov4worHBylxUL63LFyXtKi59RR5/4glxIIWlXB1P23sqzgZM5eAqKae+3wmfG0ff
EApgpX02+hneQHK1pmIZFAOw7zy3ZR2+DdqonkbzNdQ74lDlOy7MvMz1duh0nQAa
AmRDBw1scyqkDdRhjCpU/plFnOFHNuKEgIvYjgy7rNVr8mekQZ6XZg1SvSMPsiCn
4Wy/yZ981A3+4GwMO+CJ8gIpZS8t/YNIWqkYyhcN1FbcwyU31xwoAkX18IoDpIMj
pzKfAN3Q3l8WxFPrZdlc
=dXjX
-----END PGP SIGNATURE-----



More information about the bazaar mailing list