On Fri, Feb 12, 2010 at 09:39, Georg Brandl
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