I find git and hg interchangeable. What I'd like to know how to do with hg, is when I do an hg pull, it tells me the ongoing process with bytes transferred and other updated statistics, like git does.
Cheers, Richard. On 1/7/14, Christian Tismer <[email protected]> wrote: > Howdy, > > now I think I _have_ understood it after quite a long search, from > > http://docs.python.org/devguide/faq.html#how-do-i-make-a-null-merge > > but it was not very understandable before I looked up the options to see > what it does (docs written by someone who knows too much). > > So the trick is to do a merge and throw the changes away, to make hg shut up > and stop trying to merge. Waah... > > did I mention that I like git better meanwhile? ;-) > > cheers & thanks -- Chris > > > On 06.01.14 19:09, Christian Tismer wrote: >> I have still not understood the null-merge thing, but the merge (with a >> few grafts) to 2.8-slp worked fine so far. >> >> Sent from my Ei4Steve >> >>> On Jan 6, 2014, at 16:59, Kristján Valur Jónsson <[email protected]> >>> wrote: >>> >>> Yes. cPython uses merges between branches of the 2.x family, and of the >>> 3.x family. But to get a change/fix over from 2 to 3, it is grafted. >>> This is they have diverged too much for branching/merging to be >>> effective, I think. >>> >>> For 2.7 to 2.8 I would merge. >>> >>> aside: >>> Note that there is this thing called a “null merge”. this produces a >>> merge without changing any destination files, effectively setting the >>> starting position for future merges. >>> When I had merged 3.2 to 3.2-slp and 3.3. to 3.3-slp, I had to do this. >>> Normally, a merge from 3.2-slp to 3.3-slp would only bring over the >>> recent stackless-only changes. But after merging from cPython, suddenly >>> there was a lot of non-stackless changes that a merge between the >>> branches would have caused to happen (for whatever reason that is). To >>> reset the merge status, I did a null-merge between 3.2-slp to 3.3-2lp. >>> Basically, once you have your two branches in a state where you want >>> merging to produce no change to the target, but the merge algorithm still >>> wants to bring something over, you perform a null merge to reset it…. >>> </aside> >>> >>> I don’t know what the state is of 2.8-slp vs. 2.7-slp or when it was >>> branched off, but I imagine that it should just merge fine. >>> >>> From: Christian Tismer [mailto:[email protected]] >>> Sent: 6. janúar 2014 13:42 >>> To: The Stackless Python Mailing List; Kristján Valur Jónsson >>> Subject: Re: [Stackless] bitbucket processes >>> >>> On 06.01.14 13:32, Kristján Valur Jónsson wrote: >>> Hi, I just wanted to discuss our practices on BitBucket. >>> While the repo is still private, we who have access should probably stick >>> to some guidelines. >>> >>> >>> 1) Commit comments should include ticket references, so that we get >>> proper cross-references: >>> https://confluence.atlassian.com/display/BITBUCKET/Mark+up+comments%2C+issues%2C+and+commit+messages >>> and >>> https://confluence.atlassian.com/display/BITBUCKET/Resolve+issues+automatically+when+users+push+code >>> In particular, when a commit is pertaining to a ticket, use the “re #34” >>> syntax or equivalent. This should cause a link to the changeset to be >>> automatically added to the issue. >>> >>> 2) Python 3 support: IMHO, contributors should be responsible >>> themselves for porting changes/fixes to the other branches, much as is >>> the case for cPython development. For a change made in 2.7-slp, that >>> change should be grafted to 3.2-slp. 3.2-slp should then be „merged“ >>> into 3.3-slp. (once we drop 3.2-slp, we will graft directly to 3.3-slp) >>> 3.2 is still VS2008 and should be compilable and testable by all. >>> If we don‘t do this, we run the risk of divergence. I have been doing >>> synchronization sessions from time to time trying to port stuff over, but >>> it is easy to lose track, and it shouldn‘t be the responsibility of one >>> person to keep our branch tree in sync. >>> >>> 3) All fixes/changes should be accompanied by a unittest by now. >>> >>> 4) We should probaby try to write the unittests in a 2/3 neutral >>> mode (i.e. use from __future__ import print_statement). This will allow >>> us to diff the unittests between branches more easily and thus discover >>> any discrepancy. They should really be the same. Running the _same_ >>> unittests in different branches should then help us ensure that point 2) >>> is adhered to above. >>> >>> Thoughts? >>> >>> I just tried graft for the first time, and I see how it replays patches >>> exactly. >>> What is best to do for 2.8: merge or graft? >>> >>> I started merging, then reverted and tried graft. >>> Confused - merge is probably better here? >>> >>> cheers - Chris >>> >>> >>> -- >>> >>> Christian Tismer :^) >>> <mailto:[email protected]><mailto:[email protected]> >>> >>> Software Consulting : Have a break! Take a ride on Python's >>> >>> Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ >>> >>> 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de >>> >>> phone +49 173 24 18 776 fax +49 (30) 700143-0023 >>> >>> PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 >>> >>> whom do you want to sponsor today? http://www.stackless.com/ >>> <winmail.dat> >> _______________________________________________ >> Stackless mailing list >> [email protected] >> http://www.stackless.com/mailman/listinfo/stackless > > > -- > Christian Tismer :^) <mailto:[email protected]> > Software Consulting : Have a break! Take a ride on Python's > Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ > 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de > phone +49 173 24 18 776 fax +49 (30) 700143-0023 > PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 > whom do you want to sponsor today? http://www.stackless.com/ > > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
