Re: [Monotone-devel] Why are untouched files listed on branch merges/propagates?

[Stephen Leake]

"Ralf S. Engelschall" <address@hidden> writes:

> I've today recognized that the output of "mtn log" could be considered
> confusing in case of branch merges, because files which are not
> "touched" in the particular propagate operation are listed for it.
> Actually those files were "touched" in an operation before.
>
> I reduced the situation to the following trivial example:
>
> <snip>

excellent example.

> o     -----------------------------------------------------------------
> |\    Revision:  31ba4eb50c1167e091d0e5748acdc2212c362490
> | |   Ancestor:  5b2fc9555227ef39055504539cf43273b64d2e1b
> | |   Ancestor:  6b235858dde0e577d4e8a6f8a5c97942fc722de3
> | |   Author:    Ralf S. Engelschall <address@hidden>
> | |   Date:      2008-07-05T08:46:37
> | |   Branch:    branch2
> | |
> | |   Deleted entries:
> | |       file1a.txt
> | |   Added files:
> | |       file1d.txt file2a.txt
> | |   Modified files:
> | |       file1b.txt file1c.txt
> | |
> | |   ChangeLog:
> | |
> | |   propagate from branch 'branch1' (head 
> 5b2fc9555227ef39055504539cf43273b64d2e1b)
> | |               to branch 'branch2' (head 
> 6b235858dde0e577d4e8a6f8a5c97942fc722de3)

> So, do I perhaps overlook something important here or should Monotone
> actually be changed to list less files in the "mtn log" output for
> revisions resulting from "mtn propagate" operations?

I agree it looks confusing. But I believe 'mtn log' is faithfully
outputting what is stored in the database. Here's the output of 'mtn
au get_revision':

address@hidden mtn au get_revision 31ba4eb50c1167e091d0e5748acdc2212c362490
format_version "1"

new_manifest [670f3cea77f4017c369edda2ca385c98184343f1]

old_revision [5b2fc9555227ef39055504539cf43273b64d2e1b]

add_file "file2a.txt"
 content [2dcb73fb32dec17a3564648a0c713e5ff58b1320]

patch "file1c.txt"
 from [b2b5138dfb2632f2463d2d6291306d635bda45cb]
   to [f5f39b70462553be4311d0e767741e6679d117a6]

old_revision [6b235858dde0e577d4e8a6f8a5c97942fc722de3]

delete "file1a.txt"

add_file "file1d.txt"
 content [790b8e5cf794e9da7d7eeece7124fa42fea03592]

patch "file1b.txt"
 from [057851757f649ce5dac50659ab6248ef51bce530]
   to [311ba72c6c1fcfaaf92cc08a8e6ac385cda8b334]

This is the list of changes to get from each parent to the merge
result. It's clearer here, because the two lists of changes are
separated by parent. In the 'mtn log' output, they are mashed together.

Sometimes, that's what you are interested in. Other times, you
want to know the list of changes that occured "during this operation";
the files that had conflicts of some sort. In this merge, there were
no conflicts:

address@hidden mtn show_conflicts 6b235858dde0e577d4e8a6f8a5c97942fc722de3 
5b2fc9555227ef39055504539cf43273b64d2e1b
mtn: [left]  6b235858dde0e577d4e8a6f8a5c97942fc722de3
mtn: [right] 5b2fc9555227ef39055504539cf43273b64d2e1b
mtn: no conflicts detected

So I'm not clear what you want the log output to be in this case;
perhaps just empty.

It might be reasonable to add an option --merge-conflict-only, to
output only files that were changed due to conflict resolutions, if
the revision being displayed has two parents. I'm not sure that would
be easy to implement; you might have to repeat the merge computation
to recover the conflict information.

This issue becomes more significant as we add more --resolve-conflict
operations (see nvm.automate_show_conflicts). 

I guess since 'mtn propagate' is defined as an 'asymmetric merge', it
might make sense to define the revision with the same branch tag as
the result to be the "real parent", and only show the changes from that
parent to the merge result. So it might be reasonable to add an option
'--propagate-real-parent-changes-only', or something shorter with that
meaning. 

I prefer to use the automate interface and customize the display in
Emacs :).

-- 
-- Stephe