Showing content from http://mail.python.org/pipermail/python-dev/attachments/20101229/a6876c77/attachment-0001.html below:
<div class="gmail_quote">2010/12/29 David Cournapeau <span dir="ltr"><<a href="mailto:cournape@gmail.com">cournape@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":2i">The easiest way I found to emulate git cherry-pick (which does exactly<br>
what you want) with hg is to use import/export commands:<br>
<a href="http://mercurial.selenic.com/wiki/CommunicatingChanges" target="_blank">http://mercurial.selenic.com/wiki/CommunicatingChanges</a><br>
<br>
It is indeed quite a pain to use in my experience, because you cannot<br>
easily refer to the original commit the cherry pick is coming from<br>
(i.e. no equivalent to git cherry-pick -x), and the conflict<br>
resolution is quite dumb. </div></blockquote><div><br></div><div>This is precisely why I proposed a specific example.</div><div>Which precise steps do you take?</div><div>How much typing or manual copy/paste is required for this very simple case?</div>
<div><div>Can you do the merge in less than 10 minutes?</div></div><div><br></div><div>And finally the biased question:</div><div>can you find one improvement over the current situation with svn?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":2i">One alternative is to be careful about where<br>
you apply your patch<br>
(<a href="http://stackoverflow.com/questions/3926906/what-is-the-most-efficient-way-to-handle-hg-import-rejects" target="_blank">http://stackoverflow.com/questions/3926906/what-is-the-most-efficient-way-to-handle-hg-import-rejects</a>),<br>
but that's not very convenient either.</div></blockquote></div><br>I've read all this, and this method does not work, for several reasons:<div><br></div><div>- py3k / 2.7 / 3.1 cannot be ordered, there is no "earliest possible parent"..</div>
<div>we usually consider py3k as a child of both 2.7 and 3.1, and there is no common parent.</div><div><br></div><div>- even if there was one, there is the problem of changes specifically made for 2.7</div><div>that make no sense in py3k. You'd have to perform a "dummy merge" to py3k</div>
<div>which has the disadvantage of cluttering the py3k change log. And think of the horror</div><div>if someone forgets this dummy merge.</div><div><br></div><div>- in any case, the actual repositories in <a href="http://code.python.org/hg/">http://code.python.org/hg/</a> are not clones</div>
<div>of each other, so "hg merge" won't work and "hg pull" will clone the whole remote repository.</div><div>(btw, now that I have "hg pull" another repo, how can I remove it? is my clone broken forever?)</div>
<div><div><br>-- <br>Amaury Forgeot d'Arc<br>
</div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4