2010/12/29 David Cournapeau <cournape at gmail.com>: > On Wed, Dec 29, 2010 at 5:02 PM, Amaury Forgeot d'Arc > <amauryfa at gmail.com> wrote: >> 2010/12/29 David Cournapeau <cournape at gmail.com> >>> >>> The easiest way I found to emulate git cherry-pick (which does exactly >>> what you want) with hg is to use import/export commands: >>> http://mercurial.selenic.com/wiki/CommunicatingChanges >>> >>> It is indeed quite a pain to use in my experience, because you cannot >>> easily refer to the original commit the cherry pick is coming from >>> (i.e. no equivalent to git cherry-pick -x), and the conflict >>> resolution is quite dumb. >> >> This is precisely why I proposed a specific example. >> Which precise steps do you take? >> How much typing or manual copy/paste is required for this very simple case? >> Can you do the merge in less than 10 minutes? > > I don't know in this specific case. As I said, when I have to use hg, > that's the technique I use, and you get the issue you mention. That's > a hg limitation AFAICS. Yes, Georg identified three things that "hg transplant" should do better: - an option to not commit - a way to add conflict markers in the source instead of the .rej file (In this case, it may be just as easy to use the standard merge tools) - somehow share the "transplants" cache file between clones. > sometimes the people who become the most vocal proponents of the new > tool were the most sceptic ones before. I really was not sceptic before, and I certainly don't want to become one! But yesterday I was blocked the whole afternoon by something I still call an routine task with most other SCMs; and the only answer I get is "that's right, it's a pain" hg will certainly impose a change in the way we develop Python. I'm not sure everybody understands the consequences. -- Amaury Forgeot d'Arc
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