Hendrik Boom <hend...@topoi.pooq.com> writes: > Is there any way to mark this one changeset so that it will never be > merged into the main branch?
This is not possible with the current monotone. It has come up in other contexts; the Emacs developers would like the capability. (If we implement it, they just might switch to monotone :). You could do it manually with the following steps: - generate a diff file containing the changeset. - propagate from local to main - apply the diff in reverse - commit on main. That leaves one "bad revision" in main, but otherwise it's not too bad. It should be possible to do this internally, avoiding the "bad revision". But it will break if the diff fails to apply. In that case, you need to regenerate the diff somehow; maybe start a new local branch from main, add the new local config. We'd need a way to identify the changeset to revert; from/to rev ids would work. Then you can specify those revids in an option to the propagate command. Or the diff could just be in a file, not derived internally from the revision history. Then you could fix it when it breaks; that seems simpler. It could still be applied internally before committing the new revision in propagate. Hmm. It might be necessary to have propagate apply the diff forward when propagating from main to local again; I'm not clear on that. -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel