On 4/6/2011 4:45 PM, Ezio Melotti wrote:
On 06/04/2011 17.08, Antoine Pitrou wrote:
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
Le mercredi 06 avril 2011 à 15:07 +0800, Senthil Kumaran a écrit : 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