Incidentally, both examples that you list (git stash and git commit --amend) are easily handled by Mercurial Queues.
No, no, no. Let's get this myth out of the way that Mercurial Queues can somehow be part of a modern revision control system. Mercurial Queues are a simple stack of DUMB patches. The only reason why they are used is that often that is all you really need.
But the moment you need any kind of advanced functionality, such as say, something unimaginable like rebasing a Mercurial Queue against an upstream change that conflicts, you are suddenly dealing with tools that are no more advanced than diff and patch, and most certainly don't support any advanced operation on the patches that they juggle. I heard some modern tools like CVS support an advanced operation they call "merge". I'm still waiting until someone implements a usable version for Mercurial Queues.
So please, the moment you use Mercurial Queues in an argument, you've lost. Mercurial Queues are diff and patch in a fancy packaging, but with all the limitations of those. If your revision control system needs them to have the same functionality as another, you've lost.
The dirty secret is this: Mercurial users use Mercurial Queues because Mercurial got branching wrong. It's as simple as that.
In a way, the Git vs. Mercurial debate feels like vi vs. emacs all over again. Hardcore emacs users never quite understood the appeal of a modal editor; hardcore vi users couldn't quite understand how people lived with an input model that constantly moved their fingers off home row.
Emacs and vi both have their strengths and weaknesses. I've used both over the years sometimes trending to one or the other depending on the circumstances. As I've gotten to know both better, I understand the relative strengths better and know when it makes sense to use either. They're both good tools, and will both keep big user-bases for the foreseeable future.
Can I say the same about Mercurial and Git? That's a resounding NO.
I can accept that some holy wars can't have winners. But we should also be willing to accept that some tools can be just better than others.
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?
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.
> 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)
I've done this when I was submitting patches to a large git based project (perl5). The trick is to to the rebase and then re-tag your old branch. That way the old work is there if you need to reference it. Since it has a real live tag, it will not get garbage collected.
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.
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.
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).
I always see this argument about "I want to see everything that a developer did during the development process."
In reality, 'rewriting history' comes down to things like:
* Creating a commit, then amending the commit message.
* Rebasing all of your current changes on top of a new version of master (basically re-applying all of your commits/patches on top of master).
* Fixing a typo creating a commit, and then squashing that into the original commit.
(Note: That these operations all happen on topic branches prior to being merged into master. Once you merge into master, or just publish for public consumption, then you should not be rewriting history at all.)
From my perspective, the view that git is useless because the ability to rewrite history means that valuable information is being lost is an extreme overreaction by people without much (or any) git experience.
If you want to hold this view, you should have rational examples of workflows where people will lose valuable information just as a matter of course.
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?
Not sure if I agree as to what is normal and what is abuse here. If you write some feature in a branch, and have various commits for bugfixes as you go, you might want to merge those little commits away for review as well as for bisection purposes. This seems both normal and desirable to me - no one wants to review a set of 100 patches for a feature if they contain a lot of redundancy. It's useful to do small commits as you work to get a feature stable, but it isn't useful to ask someone to review all those commits, especially if they fix a previous bug introduced by another such small commit.
However, that history can still be very useful: You might hit a variation on those bugs later, and seeing the original unrewritten history can help a lot in refreshing your memory on what you did there (and it can be even more helpful for someone else getting up to speed on the code trying to fix that bug). Losing the history after history rewriting isn't a good thing.
In my experience what is being reviewed by your peers are the feature diffs, not the individual commit diffs. What the actual history looks like is entirely up to you as the coder.
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.
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-mercu.... From what I can see, Mercurial Queues look very useful.
But the moment you need any kind of advanced functionality, such as say, something unimaginable like rebasing a Mercurial Queue against an upstream change that conflicts, you are suddenly dealing with tools that are no more advanced than diff and patch
This is incorrect. "hg rebase" is more advanced and smarter than diff and patch. Also, people arguing against Mercurial seem unaware of "hg collapse" which allows rewriting history in a way similar to git.
(However I would probably not use hg rebase on Mercurial queues, which are meant to be managed by mq extension commands.)
I think most of the git vs. mercurial debates are non-productive because proponents of one tool don't know the other tool well enough to argue against it.
This is incorrect...However I would probably not use hg rebase on Mercurial queues, which are meant to be managed by mq extension commands.
You completely contradicted your own claim already.
This is exactly what I'm complaining about: Mercurial Queues are diff and patch. And you need Mercurial Queues for decent Mercurial workflows.
I think most of the git vs. mercurial debates are non-productive because proponents of one tool don't know the other tool well enough to argue against it.
I use Mercurial extensively and on a daily basis, so I think I'm qualified to talk about it. People who claim the complaint is invalid should do Mercurial users a favor and point out a workflow that avoids the issue. I'm still waiting (and manually merging all my patch queues whenever I get a conflict in a topmost patch).
> I think most of the git vs. mercurial debates are non-productive because proponents of one tool don't know the other tool well enough to argue against it.
You hit the nail on the head there. I wouldn't claim at all to know git well, despite having used it in numerous projects. On the other hand I felt like I "knew" Mercurial from the moment I picked it up. I've never written code to work around a problem (as the article suggests), and typically on the few occasions I've had problems I've remedied them by using Mercurial commands I already knew without even needing to look up documentation.
Opinions are clearly divided between two tools that perform the same task in very different ways. You can't please all of the people all of the time, long may both continue. More productive for everyone in my opinion would be ensuring bridge projects like hg-git become first-class citizens of the DVCS world.
No, no, no. Let's get this myth out of the way that Mercurial Queues can somehow be part of a modern revision control system. Mercurial Queues are a simple stack of DUMB patches. The only reason why they are used is that often that is all you really need.
But the moment you need any kind of advanced functionality, such as say, something unimaginable like rebasing a Mercurial Queue against an upstream change that conflicts, you are suddenly dealing with tools that are no more advanced than diff and patch, and most certainly don't support any advanced operation on the patches that they juggle. I heard some modern tools like CVS support an advanced operation they call "merge". I'm still waiting until someone implements a usable version for Mercurial Queues.
So please, the moment you use Mercurial Queues in an argument, you've lost. Mercurial Queues are diff and patch in a fancy packaging, but with all the limitations of those. If your revision control system needs them to have the same functionality as another, you've lost.
The dirty secret is this: Mercurial users use Mercurial Queues because Mercurial got branching wrong. It's as simple as that.
In a way, the Git vs. Mercurial debate feels like vi vs. emacs all over again. Hardcore emacs users never quite understood the appeal of a modal editor; hardcore vi users couldn't quite understand how people lived with an input model that constantly moved their fingers off home row.
Emacs and vi both have their strengths and weaknesses. I've used both over the years sometimes trending to one or the other depending on the circumstances. As I've gotten to know both better, I understand the relative strengths better and know when it makes sense to use either. They're both good tools, and will both keep big user-bases for the foreseeable future.
Can I say the same about Mercurial and Git? That's a resounding NO.
I can accept that some holy wars can't have winners. But we should also be willing to accept that some tools can be just better than others.