Patches in your patch queue are part of history, but they are not yet permanent, so they are mutable. You cannot change their contents or rearrange them, because that would change their hashes, which Mercurial uses to uniquely identify them. If you're fastidious, you'll fall in love with this the first time you do it, because this process lets you keep separate changes in separate commits, never mixing them and rarely having to pull them apart.Ĭommits that are part of permanent history are immutable. Add any outstanding portions of that change into your current patch.Momentarily stop working on the original change.Fix it now, and confound your next commit with both what you were originally working on and the fix for the problem you discovered.
Promise to yourself that you'll remember this other problem, then forget it a few minutes later.Without mq, when this happens, you have three choices: More probably, though, the file is already dirty with some portion of the original change. If you're lucky, the file where you found this other problem is as yet unmodified, so you can safely commit the fix for the new problem separately from whatever you were originally working on. It could be anything from a style issue to another bug, unrelated to the one you're working on. Often, while developing one change, you'll notice something else that could use improvement. Preventing the tangled-working-copy problem Then, while further refining the patch, if you decide that you're moving in the wrong direction and want to get back to a known-good state, you can use hg's revert command to bring things back to the state you last saved in the current patch.Ģ.2. While working on a patch, when you arrive at a point that is not yet ideal but does work, use qrefresh to refresh your current patch with the current state of the project. Save a known-good but not yet perfect version of a change (original version by dustin sallings, mercurial mailing list, )Ģ.1. qpush and qpop will help you move up and down while keeping your changes separate. You can, for example, work on two different layers of your application (something low-level and something built on top of that) in the same queue at the same time without breaking stuff. The patch queue aspect is actually quite nice as well. You can revision control the queue itself by using hg commit -mq to save the state of your patch queue. Hg qfinish some-changes-i-want-to-make # Make the patch a permanent commit
#Mercurial windows tutorial update#
Hg qrefresh # update the patch with still yet newer changes Hg qrefresh # update the patch with the new changes You can keep revising a changeset until it's good enough, then transfer control to regular Mercurial. The mutability is exactly what it sounds like you're looking for. It's basically just orthogonal, mutable changesets. It's one of those things that sounds a lot harder than it is.
0 kommentar(er)
