[python-committers] Fwd: [Python-checkins] cpython (merge 2.7 -> 2.7): hg pull/merge - Changes to accomodate.

[Terry Reedy]

On 4/6/2011 4:45 PM, Ezio Melotti wrote:
> On 06/04/2011 17.08, Antoine Pitrou wrote:
>> Le mercredi 06 avril 2011 à 15:07 +0800, Senthil Kumaran a écrit :
>>> The below changes were from Alexander Belopolsky. When I tried to push
>>> my changes, my changes resulted in multiple heads in 2.7, so I had to
>>> go back 2.7 branch, merge 2.7 and then commit and push. This resulted
>>> in both my changes as well as merged changes being pushed.
>> Well, this is normal. Do understand that history with a DVCS is not
>> linear. You have based your changes on an earlier revision (for whatever
>> reason - for example someone pushed a new revision in-between), and so
>> you had to merge - reconcile - your changes with the latest upstream
>> changes. This is normal practice.
>>
>> I guess you have been surprised by the diff in the notification e-mail,
>> which makes it look like that the datetime changes have been committed
>> "twice". The diff displays the differences between the merge changeset
>> and one of its parents (the first one, probably). So, it will reflect
>> the changes made necessary to one of its two parents in order to
>> reconcile it with the other; it "appears" (due to the diff) that some
>> changes have been committed twice, but it's only so if you consider
>> history linear as in SVN.
>>
>> I think the representation of merges as a diff against one of the
>> parents is indeed sub-optimal. OTOH, it's not easy to come up with
>> something better.
>
> FWIW I've been trying to tweak the mail hook to show only the chunks
> that are actually changing something on hg.python.org (h.p.o).
> In a merge on the same branch (e.g. 2.7 -> 2.7), the diff in the mail
> shows the pulled changes. So if Senthil commits something, pulls
> Alexander changes and merges, the diff will show Alexander changes.
> That's correct from Senthil repo's point of view. The problem is that
> the mail hook does the same and shows us Alexander changes again instead
> of making a new diff from h.p.o points of view.
>
> Technically same-branch merges could be ignored, because we already got
> mails for both the parents (i.e. Senthil and Alexander changes). Who
> makes the merge might change something in the meanwhile though, so we
> want to extract these extra changes from the merge to see and review them.
> This turned out to be quite complicated, and I couldn't find any
> approach that works reliably in all the cases.
>
> The easiest solution I found to see only what changed on h.p.o is to use
> a changegroup hook instead of an incoming hook, in order to get all the
> commits at once (when a committer pushes) and make a single diff.
> The "whole diff" mail could be sent only when the push includes a
> same-branch merge (in addition or instead the per-commit ones), and have
> the same per-commit mails when there are no same-branch merges.
>
> Another way to find changes is to make crossed checks, but that doesn't
> work too well in complex cases.
> This means:
>
> /-> A -\
> -P M
> \-> S -/
>
> (P=parent, A=Alexander, S=Senthil, M=merge)
>
> Assume that Alexander committed his change in A and Senthil committed
> his change in S, then:
> * the diff from A and M should be equal to the diff from P and S, and
> * the diff from S and M should be equal to the diff from P and A.
> If both the diffs are not equal, something else changed.

Like Senthil, I have been puzzled by the duplicate diffs. think it might 
help other hg newcomers if something like the above were in the dev docs.

>
> This is similar to the algorithm used b the MergediffExtension, and can
> be extended to work in this case too:
>
> /-> A1 -> A2 -> A3 -\
> -P M
> \-> S1 -> S2 -> S3 -/
>
> but if the case is like this it starts to get complicated:
>
> /-> A1 -> A2 -> A3 -> A4 -\
> -P \ M1
> \---> S1 --> M0 --> S2 ---/
>
> (i.e. Senthil does some changes (S1), pulls and merges what Alexander
> pushed on h.p.o (A1/A2), does more changes (S2), pulls and merges
> another set of changes pushed by Alexander (A3/A4) -- this might be
> common with long-term feature branches.)
>


Terry