3 ms·

maybe I am misunderstanding your question. Can you give me an example?

regularfry 14y ago
With git, you can have more than one experimental branch going at once, with more than one commit in each, and switch between them at will. I don't know how to do that with mercurial. It might be possible with a version controlled queue, but if it is I don't know the cli calls to make it happen. Here's a hypothetical git workflow: git checkout -b experiment_1 git commit -m "A" git commit -m "B" git checkout master git checkout -b experiment_2 git commit -m "C" git commit -m "D" At this point, I've got one experiment going with A and B, and another with C and D, both branching from the same master commit. My understanding of mq is that I could have either experiment_1 or experiment_2, but not both. Admittedly it's a situation which doesn't come up often, but it's just often enough that I'd be intrigued if hg could do the same.
- tbatterii 14y ago
  I do that by pushing, popping and reordering patches. For example right now in my queue I have a patch to disable http throttling on our main app which will never be checked in, a patch for a major refactoring of the data layer that might not fly, but the work is more significant than a couple days work, an upgrade to a new version of the sdk in another patch, a re-working of the docs patch etc.... I qpush whatever I want to work on between bug fixes which go directly to the development branch. so something like.... hg qpush --move nothrottle.patch hg qrfresh # repeat etc... hg qpop # unapply patch from working directory hg qpush --move membership_schema_refactor.patch hg qrefresh # repeat etc.... hg qpop #unapply I haz bug to fix hg commit -m "fix this bug" hg push && hg pull && hg update development # do the sync dance hg qpush --move membership_schema_refactor.patch hg qfinish -a # change applied patches to changeset Between the popping in pushing, I can switch to whichever branch revision I want assuming whichever patch applies cleanly. Not saying it's the same as the hypothetical workflow in git, but it is how I handle multiple seemingly unrelated lines of development for better or worse. Hell of a lot more flexible than what I would have to do in perforce before they added shelving etc.... :)
  - regularfry 14y ago
    It does seem that mercurial is encouraging a workflow which is basically "get everything into one patch before committing it" whereas git says "take as many commits as you want to get it right, you can squash it later if you want."
    - tbatterii 14y ago
      based on my example, yeah I can see where you would think that. But that example wasn't meant to be the definitive be all end all hg workflow. just an example of how one person(me) keeps multiple lines of unrelated development straight in their head. Changesets can be converted to patches, patches can be folded into patches, series of one or more patches can be converted to one or more changesets. IMO, if there's any edge case that all that doesn't provide, I probably don't need it.

With git, you can have more than one experimental branch going at once, with more than one commit in each, and switch between them at will. I don't know how to do that with mercurial. It might be possible with a version controlled queue, but if it is I don't know the cli calls to make it happen. Here's a hypothetical git workflow: git checkout -b experiment_1 git commit -m "A" git commit -m "B" git checkout master git checkout -b experiment_2 git commit -m "C" git commit -m "D" At this point, I've got one experiment going with A and B, and another with C and D, both branching from the same master commit. My understanding of mq is that I could have either experiment_1 or experiment_2, but not both. Admittedly it's a situation which doesn't come up often, but it's just often enough that I'd be intrigued if hg could do the same.

tbatterii 14y ago
I do that by pushing, popping and reordering patches. For example right now in my queue I have a patch to disable http throttling on our main app which will never be checked in, a patch for a major refactoring of the data layer that might not fly, but the work is more significant than a couple days work, an upgrade to a new version of the sdk in another patch, a re-working of the docs patch etc.... I qpush whatever I want to work on between bug fixes which go directly to the development branch. so something like.... hg qpush --move nothrottle.patch hg qrfresh # repeat etc... hg qpop # unapply patch from working directory hg qpush --move membership_schema_refactor.patch hg qrefresh # repeat etc.... hg qpop #unapply I haz bug to fix hg commit -m "fix this bug" hg push && hg pull && hg update development # do the sync dance hg qpush --move membership_schema_refactor.patch hg qfinish -a # change applied patches to changeset Between the popping in pushing, I can switch to whichever branch revision I want assuming whichever patch applies cleanly. Not saying it's the same as the hypothetical workflow in git, but it is how I handle multiple seemingly unrelated lines of development for better or worse. Hell of a lot more flexible than what I would have to do in perforce before they added shelving etc.... :)
- regularfry 14y ago
  It does seem that mercurial is encouraging a workflow which is basically "get everything into one patch before committing it" whereas git says "take as many commits as you want to get it right, you can squash it later if you want."
  - tbatterii 14y ago
    based on my example, yeah I can see where you would think that. But that example wasn't meant to be the definitive be all end all hg workflow. just an example of how one person(me) keeps multiple lines of unrelated development straight in their head. Changesets can be converted to patches, patches can be folded into patches, series of one or more patches can be converted to one or more changesets. IMO, if there's any edge case that all that doesn't provide, I probably don't need it.