Re: Presenting net code changes for a branch

Branko Čibej wrote:
> Here's a more complete proposal:
>
> Introduce two new revision keywords:
>
>     * ROOT (alternatively: CREATED)
>       [...]
>
>     * MERGED
>       Only relevant in the context of a branch. Represents the latest
>       revision in which a merge was made to the branch. This revision
>       may depend on a discriminator parameter, which is a branch URL,
>       such that the result is the revision of the latest merge from
>       that branch.

This doesn't address the use case at hand. In order to see the net code changes on a branch, the left-hand side of the diff needs to be the *base* of the last merge, otherwise known as the "youngest common ancestor in the merge graph".

Let's review why that is so.

    1  2  3  4  5  6  7
  T ---------o--------o-
     \        \
      \        \
  B    o--o-----o--o----

The net code changes on this branch consist of the logical "combination" of the changes B3 and B6. (Assume no additional changes were made during branching or merging). However, an attempt to compute the net change by simply combining the individual changes (B3 "plus" B6) is likely to fail due to conflicts, because one was made in an older context and the other in a newer context (after the catch-up from trunk).

But we observe that the user has already combined changes B3 and B6 on the branch, including any conflict resolution that may have been necessary in relation to the catch-up from trunk, in two stages: first the catch-up merge resulting in state B_at_5 containing the logical combination of (B3 "plus" T4), and then the commit resulting in a state B_at_6 containing ((B3 "plus" T4) "plus" B6).

To see the net code changes on the branch, then, we can take the branch tip (state B_at_6) and subtract the last caught-up-to state of trunk (state T_at_4). Thus, diff(T_at_4,B_at_6). It is not diff(B_at_5,B_at_6) nor diff(B_at_anything,B_at_6).

The base of the last merge, T_at_4, is typically NOT on the same branch as the right-hand side of the diff (B_at_6). (But it would be if the last merge between branch and trunk had been in the other direction, aka a "reintegrate".)

The diff scenario we're looking at is also exactly the same as saying "show me one side of the 3-way diff that would be performed if I requested an automatic merge to trunk". So another valid way to approach the problem is to see about making a "show me the diff" variant of the merge command, rather than a "show me what would be merged" variant of the diff command.

- Julian
Received on 2013-10-24 11:04:04 CEST