What is a modification?

[Martin von Gagern]

On 07.10.2011 09:19, Robert Collins wrote:
> Doesn't difftastic address to given sensible 'what really changed'
> diffs - e.g. in 1.2.3 it could show the changes made to accomodate the
> merge without showing the merge changes themselves?

Never heard of difftastic before, and couldn't find a usable referece
quickly. Can you give me a pointer on that?

What do you mean by "changes to accomodate the merge" and "merge
changes"? Is "merge changes" what "bzr merge" does automatically, and
"changes to accomodate the merge" what I have to do manually to resolve
conflicts? In my example, I assumed no manual intervention, e.g.
different files. So in 1.2.3, all changes would be coming from the merge
itself, but so would those in 3. That's what I called INHERITED. I don't
see diftasstic giving us a reason to show 3 but not 1.2.3.

What you write makes me imagine difftastic as a tool which identifies
edits that happened after an automatic file content merge but before the
corresponding commit. If that is the case, then it only applies to my
setup if we want to talk not only about ORIGINAL and INHERITED
modifications but AUTOMATIC modifications as well, which are
modifications producing a file different from all its parents, but still
occurred during a merge without user intervention.

I believe that identifying automatic merges after the fact is leading in
the wrong direction: with bzr merge hooks, anything could be part of an
automatic merge. You could uncompress binary files, perform some kind of
xml merging, recompress the result, whatever. Detecting all of this is
beyond bzr. So instead of detecting such automatic merges after they
happened, I believe that it would be best to store that information when
committing.

So I imagine the following: when you do a merge, there are some files
for which the content has to be merged as well, because both branches
have diverged from a common ancestor. So in that case, I imagine some
merge hooks are given a chance to merge these files. If they succeed,
bzr could store the hash of that automatic merge in some location for
later reference. When you commit the merge, the commit command could
look at these files again, and compare their current hashes to what was
stored after automatic merging. If the hashes agree, you can assume that
the branches were merged automatically without any manual user
intervention, and store that fact in some kind of revision property.

There are some drawbacks to this approach, though. For one, it obviously
won't work for past commits, which happened before this feature was
deployed. Secondly, merge hooks might ask questions, in which case the
merge isn't so automatic after all. The hook API should provide
information on that, but I guess currently it does not.

So much about automatic merges. Let me know if I'm completely off target
here.

 Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20111007/8ccdb9a9/attachment.pgp>