when merged more files are listed as changed

[Simon King]

Before the merge, r98 is the tip of branch1, and r99 is the tip of
branch2. r100 is the result of merging the two branches. So the diff
between *r98* and r100 shows the changes that have been merged into
branch1 from branch2. r97 is not relevant.

r97 was relevant to the merge *operation*, because it is the common
ancestor of r98 and r99, but once the merge commit has been created,
it's not important any more.

Simon

On Thu, Jun 4, 2015 at 1:07 PM, Prabhakar S <prabhakar.s at tegile.com> wrote:
> Thank you Simon. Your explanation did help me.
>
> However, I have few more questions.
>
> We are having two repos forked from a base repo. And these two repos am
> going to call as branch1 and branch2. We are periodically pullying from
> branch2 -> branch1
>
> And if you consider the graph below.
>
> The diff for the commit of change:100 should be from the hg diff -r 97 -r
> tip
>
> tip is 100 and the diff to the next changeset is , the next merge point what
> has been merged which is 98. And the 97 actually contributed to 98 and hence
> I understand the diff is from
>
> hg diff -r 97 -1 100 and this is from the branch1 perspective, as we merge
> only from branch2 to branch1.( cross pull)
>
> However, the diff should only show changes of few files which changed
> between the two snapshots one is 100 and one is the 97 snapshot. It really
> cannot show many changes.
>
> And between changeset 95 and 97 there are lesser changes. Since already
> changeset :96 is already there as a result of merge. The diff simply cannot
> show changes beyond changeset:96
>
> Help me to interpret the diff correctly. But, I believe as it is not
> breaking anything, it is doing correct things, but what it shows of as the
> diff during merge sometimes is actually more than the files changed. This I
> have seen to occur sometimes and not always.
>
> @     changeset:100 [ changeset in branch1 ]
> |\
> | |
> | |
> | |
> | |
> | o  changeset:99 [ changeset in branch 2 ]
> | |
> | |
> | |
> | |
> | |
> | |
> o | changeset:98 [ changeset in branch1 , contributed by merge ]
> |\|
> | |
> | |
> | |
> | |
> | |
> | |
> | o changeset:97 [ changeset in branch 2 ]
> | |
> | |
> | |
> | |
> | |
> | |
> | |
> | |
> o | changeset:96 [ Changeset in branch 1 , contributed by merge ]
> |\|
> | |
> | |
> | |
> | |
> | |
> | |
> | |
> | |
> | o changeset:95 [ changeset in branch 2]
> | |
>
>
> Regards,
> S.Prabhakar
>
> On Thu, Jun 4, 2015 at 2:27 PM, Simon King <simon at simonking.org.uk> wrote:
>>
>> On Thu, Jun 4, 2015 at 6:49 AM, Prabhakar S <prabhakar.s at tegile.com>
>> wrote:
>> > On Wed, Jun 3, 2015 at 11:08 PM, Matt Mackall <mpm at selenic.com> wrote:
>> >>
>> >> On Wed, 2015-06-03 at 18:44 +0530, Prabhakar S wrote:
>> >> > Greetings,
>> >> >
>> >> > We have a scenario where for two releases we are having two repos and
>> >> > sometimes when the two repos are merged, say repo_REL1 is merged to
>> >> > repo_REL2 and for some conflicts with two or three files .
>> >> >
>> >> > Once they are resolved and pushed, the notification email from hg
>> >> > shows
>> >> > ,
>> >> > more number of files as changed than expected.
>> >> >
>> >> > When i checked that , looks like it is generated using command below
>> >> >
>> >> > hg diff -r <tip> -r <priortotip_notsure_ifitisexact prior_to_tip> |
>> >> > diffstat
>> >>
>> >> By default, it's going to show the difference between a commit and its
>> >> first parent.
>> >>
>> >> > Now the question is
>> >> >
>> >> > 1. Is the hg notification using the above approach to send the list
>> >> > of
>> >> > modified files ?
>> >>
>> >> Roughly.
>> >>
>> >> > 2. Why is it showing more files as modified though only few files are
>> >> > modified ?
>> >>
>> >> If, for instance, you merge your development branch into your release
>> >> branch with no conflicts.. the diff is still going to show _all your
>> >> development_ because all those files have changed.
>> >>
>> >
>> > Thank you for the details.
>> >
>> > When I checked that, yes according to the information above, when i run
>> > a
>> > diff between the tip revision and the first parten it shows lot files in
>> > the
>> > diffstat.
>> >
>> > What Iam not able to understand is, when I run 'hg diff -c
>> > <first_parent> ,
>> > then only one file shows up, however when the diff is run between the
>> > tip
>> > and the first_parent lot of files are shown up.
>>
>> "hg diff -c <first_parent>" means "show me the diffs that were
>> introduced in <first_parent>". That has no relevance at all to the
>> diffs introduced by the merge.
>>
>> Imagine this graph:
>>
>> 1-2-3-6
>>  \   /
>>   4-5
>>
>> 1 is the common ancestor. 2 and 3 were changes made on the first
>> branch, and 4 and 5 were made on the second branch. 6 is the merge
>> revision, so 3 is the first parent of the merge, and 5 is the second
>> parent. "hg diff -c 3" will show you the diffs between 2 and 3, which
>> is probably not what you were looking for.
>>
>>
>> >
>> > I understand that , if say 10 files are modified in a changeset_A and if
>> > it
>> > is merged to a release repo, and if no conflicts also, all those 10
>> > files
>> > are going to be shown as modified.
>> >
>> > It would be great, if you give some good pointers to understand how this
>> > is
>> > handled.
>> >
>>
>> Don't think of a revision as a set of changes - think of it as a new
>> snapshot of the entire state of the repository. When you use "hg
>> diff", you are asking for the differences between 2 snapshots. A merge
>> is just another snapshot.
>>
>> The diffs introduced by a merge depend on your point of view. If you
>> were previously looking at the first parent, it would appear that the
>> merge had introduced all the changes from the second parent's branch.
>> However, from the second parent's point of view, it appears that all
>> the changes from the *first* parent's branch have suddenly appeared.
>>
>> In terms of the graph above, the diffs from 3 to 6 would show all the
>> changes that had been merged in from 4 and 5. But the diffs from 5 to
>> 6 would show all the changes from 2 and 3.
>>
>> Does that help at all?
>>
>> Simon
>
>