I went looking for Mercurial documentation about how to rebase and found this:
> Rewriting of history has ramifications if you’ve previously pushed those commits elsewhere. In Mercurial, you simply cannot push commits that you later intend to rebase, because anyone pulling from the remote will get them. In Git, you may push commits you may want to rebase later (as a backup) but only if it’s to a remote branch that only you use. If anyone else checks out that branch and you later rebase it, it’s going to get very confusing.
Git does not tell me what I cannot do. Can you explain how this documentation is wrong, or how I'm wrong for what I want to do here? I'm talking about "git pull --rebase"
Because in Git, I know that canonical wisdom is you should not rebase a branch once it's published, but Git does not tell me what I cannot do, and it happens all the time ("Committer, master has moved some since your PR was submitted, please pull rebase.") Out of respect for contributors time (and some of whom won't know what to do, and may spend time struggling to figure it out...), I would probably not rewrite a commit that's been published in a master branch, but I will absolutely rewrite commits all the time on branches that are not yet merged.
So, can you explain how this workflow goes in Mercurial? (Or why it's unnecessary?) Because from briefly perusing the first document I could find about my question, it looks like Mercurial cannot be used to solve this problem (the solution of which, I find to be a fundamental and very important part about how Git works.)
Then committer can either 'git push --force' which apparently is not allowed by mercurial too? Or create a new branch.
I try to clean up working branches when they are not needed anymore. I get the idea that Mercurial users think I shouldn't do that, or that I shouldn't share my working branches.
Although I'm not a power user, I believe mercurial can do pretty much most things that git does - including editing history. They just make the easy stuff easy and make the advanced stuff harder - as opposed to git which puts them all on an equal footing.
For history editing, people use the evolve extension in mercurial. It'll likely never become part of the default mercurial because there is a small chance of breaking backward compatibility.
Even before the evolve extension, there were ways to modify mercurial history.
Yes, mercurial docs leave something to be desired. But the actual interface is much cleaner than git's, and is much more newbie friendly, without really losing anything sophisticated.
As another user said in another comment:
>It's easier to transition to Mercurial but once you find you need to dive deep, it's just about as complex as git. Git seems to throw you in the deep end immediately which I do think is more of a blessing than a curse but there are times when it doesn't quite feel that way.
Thanks for telling, I found the rebase extension on my own but I don't know what Mercurial users are using unless you tell me and I would not have found the evolve extension on my own :D
I will probably check it out, to be fair it seems unlikely to "unseat the incumbent" git, but I've sampled my fair share of VCS including Git, SVN, CVS, RCS, Fossil, and have never really made it around to Mercurial. None of those others that I know of recently seem to have a vocal following, other than both of Git and Mercurial now, I guess.
>I will probably check it out, to be fair it seems unlikely to "unseat the incumbent" git
It will not, as they are more or less the same. People already on git have no good reason to switch. The only real benefit mercurial has is being friendlier. It may prove beneficial for new teams, but these days most people are already familiar with git and will put up with its pains (or rather, be oblivious to its pains).
Mostly an accident of history. If mercurial had initially gotten popular, I doubt anyone would be using git today.
> Rewriting of history has ramifications if you’ve previously pushed those commits elsewhere. In Mercurial, you simply cannot push commits that you later intend to rebase, because anyone pulling from the remote will get them. In Git, you may push commits you may want to rebase later (as a backup) but only if it’s to a remote branch that only you use. If anyone else checks out that branch and you later rebase it, it’s going to get very confusing.
Git does not tell me what I cannot do. Can you explain how this documentation is wrong, or how I'm wrong for what I want to do here? I'm talking about "git pull --rebase"
Because in Git, I know that canonical wisdom is you should not rebase a branch once it's published, but Git does not tell me what I cannot do, and it happens all the time ("Committer, master has moved some since your PR was submitted, please pull rebase.") Out of respect for contributors time (and some of whom won't know what to do, and may spend time struggling to figure it out...), I would probably not rewrite a commit that's been published in a master branch, but I will absolutely rewrite commits all the time on branches that are not yet merged.
So, can you explain how this workflow goes in Mercurial? (Or why it's unnecessary?) Because from briefly perusing the first document I could find about my question, it looks like Mercurial cannot be used to solve this problem (the solution of which, I find to be a fundamental and very important part about how Git works.)