On Fri, Feb 12, 2010 at 09:39, Georg Brandl <g.brandl at gmx.net> wrote: > No, it does not. This is also a concern for the Python 2 -> Python 3 merging, > where (I think) we decided not to have shared history. Transplant already I don't think this is similar to 2 vs. 3, because 2 vs. 3 are full branching (so you could still use "normal" hg merge tracking there). Since hg doesn't do merge tracking on the directory level, you couldn't use Mercurial merges (or transplant, AFAICS) to do what you want here. > does most of the job (including recording the source hash of transplanted > changesets), but it lacks blocking and consistent rejection of already-merged > changesets (it does not read the source hashes it records, but keeps a local > cache of such hashes instead, which obviously doesn't do anything across > repositories.) I think it should be possible to have transplant regenerate > and update that cache automatically on clone/pull/etc. > > I guess this is a relatively simple task for a Mercurial hacker, and if it's > decided to use this workflow "someone" ;) could address it at the PyCon sprint. Yes, we should figure out some workflow issues soon. Cheers, Dirkjan
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