Hacker News new | past | comments | ask | show | jobs | submit login

If you "git push" after rebasing published commits, you get an error, unless you use "--force" or you pull and merge manually before hand.

So I'm still not sure the distinction you are making between which one is "immutable" and which one isn't.




Phases catch this problem early before `git push`. You don't want to run into the problem too late. Then you'll be faced with the decision to throw out your work because you accidentally rewrote something that should not have been rewritten. Or you'll have to decide at the last minute that you really did mean to make problems for everyone else.

Btw, with Mercurial Evolve, there's no need to force-push, as Evolve will propagate meta-history to other users that indicates what commits replace which ones.


Ok so it has nothing to do with immutability, it's just one warns earlier than the other.

Thanks for clarifying.


It is about immutability. No Mercurial command (histedit, rebase, uncommit, amend) will allow you to change an immutable (public) commit unless you first force it back into the draft phase.

You can say that because you can always force public commits into drafts that they're not really immutable, but that's a bit of a perversion of what Mercurial's phase system is intended to do.


And no git command lets you change what public history looks like unless you --force the push.

So the check is in a different place. That doesn't seem to me to imply that Mercurial's history is "immutable" and git's is "mutable", especially since those words have precise meanings, and even WITH the --force, git doesn't change anything in the history, it just writes out a new history and updates the branch ref to point to the new history.

The only thing mutated (in both systems) is the ref to the branch head, right? So aside from warnings and errors being in different places (both before publish time), what is the difference between the two that leads you to argue that one is immutable and one isn't?


I think what Mercurial brings here is that even if you have a repo and you do a force-push you keep all the heads. Thus it's almost like a history of changes.

I think if you do a code-review and you get the final state of the repo to check, you can nicely tell how it was evolved/squashed/re-ordered.

I find that workflow much more useful than just rewriting history like in git (i know about reflog)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: