[python-committers] Fwd: [Python-checkins] cpython (merge 2.7 -> 2.7): hg pull/merge
Terry Reedy
tjreedy at udel.edu
Thu Apr 7 01:45:33 CEST 2011
More information about the python-committers mailing list
Thu Apr 7 01:45:33 CEST 2011
- Previous message: [python-committers] Fwd: [Python-checkins] cpython (merge 2.7 -> 2.7): hg pull/merge - Changes to accomodate.
- Next message: [python-committers] Contributor Agreement - Clemens
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [python-committers] Fwd: [Python-checkins] cpython (merge 2.7 -> 2.7): hg pull/merge - Changes to accomodate.
- Next message: [python-committers] Contributor Agreement - Clemens
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the python-committers mailing list