4 ms·

I disagree (and we have already had this argument I think ;). Mercurial Queues are different from git branches, not just "worse". With MQ, and especially with

by azakai 15y ago

I disagree (and we have already had this argument I think ;). Mercurial Queues are different from git branches, not just "worse". With MQ, and especially with a versioned MQ directory, you have a great workflow for review-ready patches. And review-ready patches are what you are creating, after all, in most large projects: You do some work, you refactor that work N times, then you submit it for review, then you repeat that M times until it passes review and you push it to trunk. With MQ, you can see the entire history of your set of patches. If you have a queue and you refactor two patches into one, you can go back in history in the versioned MQ dir to see what things were like before that. That is useful, because again, the "product" you are creating is a set of review-ready patches. So versioning the patches makes sense. I understand that you can use git branches very effectively - I use git myself, not mercurial. However, if you use git to rewrite the history of your branch as part of your development process, AFAIK there is no way to go back in time and instantly see what your branch looked like at time K in the past, because history has been rewritten. Rewriting history is great - you don't want to submit for review a huge list of patches that include bugfixes as you were working. You want to submit the final patches. But what if you do need to look at the state your work was in the past, before you rewrote history?

gcp 15y ago
Mercurial Queues are different from git branches, not just "worse". Mercurial Queues are bolted onto Mercurial and you can often see the cracks. Merging is my pet peeve which I've already mentioned. I think it's not controversial to say that it's a pain? I think that, in true Mercurial tradition, there's an extension in development for it now... So why do we need to deal with this bolt-on and the resulting pain? Because Mercurial branches aren't good enough, or at least can't adequately support the workflow people need. Compare the amount of Mercurial users using mq to the amount of git users using quilt or equivalents. I don't disagree with the abstract principle of operation of Mercurial Queues. I disagree with Mercurial as it is. However, if you use git to rewrite the history of your branch as part of your development process, AFAIK there is no way to go back in time and instantly see what your branch looked like at time K in the past, because history has been rewritten. 1) It may be possible to do this with reflog. I don't know for sure because I haven't needed to do this yet. (I think the main problem is that by default reflog purges old history at some point) 2) You can simply create more branches as you go. i.e. replace qcommit by git checkout -b etc. Then push the final ones.
- azakai 15y ago
  I agree that MQ has some pain points. Merging, as you say. But git branches also have pain points. The only way to save history from before you rewrite history is to save branches, as you mentioned - but doing that manually every time you rewrite history is a pain.
  - sofal 15y ago
    Actually the history is kept by reflog for 90 days by default I believe (and you can change this). This covers the large majority of cases where you have completely screwed up your history rewriting and need to go back to a state you remembered you were in.
    - azakai 15y ago
      90 days, or any other finite amount, isn't a solution for what I want. I don't need a quick undo if I erred, I want to see the development process that went into creating some code that later was committed into trunk (and perhaps much much later turned out to have a bug).
      - gcp 15y ago
        I want to see the development process that went into creating some code that later was committed into trunk (and perhaps much much later turned out to have a bug). With your MQ workflow, you can only ever do this for your own patches.
      - sofal 15y ago
        This probably comes down to discipline, meaning that when you rewrite history in git you may want to take care that you're keeping the useful bits of it and not just squashing everything down to get fat feature-rich commits. Do you think that the history-rewriting tools in git are too often abused by the average git user such that the use of git in general has the problems you've described?
        15y ago
alwillis 15y ago
I think Steve Losh, who's written a series of insightful posts on the differences between Git and Mercurial, has a great one on Mercurial Queues: http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercu.... From what I can see, Mercurial Queues look very useful.

by azakai 15y ago

gcp 15y ago

Mercurial Queues are different from git branches, not just "worse". Mercurial Queues are bolted onto Mercurial and you can often see the cracks. Merging is my pet peeve which I've already mentioned. I think it's not controversial to say that it's a pain? I think that, in true Mercurial tradition, there's an extension in development for it now... So why do we need to deal with this bolt-on and the resulting pain? Because Mercurial branches aren't good enough, or at least can't adequately support the workflow people need. Compare the amount of Mercurial users using mq to the amount of git users using quilt or equivalents. I don't disagree with the abstract principle of operation of Mercurial Queues. I disagree with Mercurial as it is. However, if you use git to rewrite the history of your branch as part of your development process, AFAIK there is no way to go back in time and instantly see what your branch looked like at time K in the past, because history has been rewritten. 1) It may be possible to do this with reflog. I don't know for sure because I haven't needed to do this yet. (I think the main problem is that by default reflog purges old history at some point) 2) You can simply create more branches as you go. i.e. replace qcommit by git checkout -b etc. Then push the final ones.

azakai 15y ago
I agree that MQ has some pain points. Merging, as you say. But git branches also have pain points. The only way to save history from before you rewrite history is to save branches, as you mentioned - but doing that manually every time you rewrite history is a pain.
- sofal 15y ago
  Actually the history is kept by reflog for 90 days by default I believe (and you can change this). This covers the large majority of cases where you have completely screwed up your history rewriting and need to go back to a state you remembered you were in.
  - azakai 15y ago
    90 days, or any other finite amount, isn't a solution for what I want. I don't need a quick undo if I erred, I want to see the development process that went into creating some code that later was committed into trunk (and perhaps much much later turned out to have a bug).
    - gcp 15y ago
      I want to see the development process that went into creating some code that later was committed into trunk (and perhaps much much later turned out to have a bug). With your MQ workflow, you can only ever do this for your own patches.
    - sofal 15y ago
      This probably comes down to discipline, meaning that when you rewrite history in git you may want to take care that you're keeping the useful bits of it and not just squashing everything down to get fat feature-rich commits. Do you think that the history-rewriting tools in git are too often abused by the average git user such that the use of git in general has the problems you've described?
      - 15y ago

alwillis 15y ago

I think Steve Losh, who's written a series of insightful posts on the differences between Git and Mercurial, has a great one on Mercurial Queues: http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercu.... From what I can see, Mercurial Queues look very useful.