$ git init --bare --shared foo.git
Initialized empty shared Git repository in foo.git/
$ cat foo.git/config
# ...
[receive]
denyNonFastforwards = true[receive] onlyFastForwards = true
However, we are a small team consisting of mostly Linux kernel developers, so that may influence the level of trust we put in not screwing things up. We also work pretty much independently; were that not the case, this would get ugly.
What team is that, and what are you working on?
Amazingly useful for making sure patches are easy to apply while following a remote branch.
My biggest problem with hg is the lack of real topic branches and how they become impossible to delete -- and having to use things like quilt on top to try to make local branches more sane -- but it's frustrating because it's not the same thing.
I consider Mercurial Queues as one of Mercurial's youthful mistakes. It was ok in 2005, but we have much better things with bookmarks, histedit, and rebase and even with hg commit --amend.
Evolve is basically the last nail in MQ's coffin.
We were discussing the advantages of Mercurial having publishable rebases.
That can be a feature or a bug.
This would be wildly useful for a public branch that needs periodic rebasing, because unlike a git rebased branch, you'd have a history of the rewrites.
On the other hand, most users who locally use git rebase -i to transform a local series of WIP patches into a sensible patch series for submission do not want any record of the intermediate commits (which may not bisect, or even build, and which may have commit messages like "WIP: try fixing it again"). git makes it easy and sensible to commit early and often, and then sort out a sensible patch series from the result.
For the case when you want to push out to the world… Well, that's mostly for catastrophic things—oh, no I accidentally checked in the private key! In that case I also don't want the history of that kept around.
So I don't know. I like the idea, but I'm not sure when it's applicable.
That's just a habit you acquired because right now rewriting public history is a "problem". It shouldn't be a problem. In fact, it's something people do, e.g. how about being able to edit a pull request as it's being discussed and it being ok if that pull request gets merged as it's being discussed?
There are all these different levels of "saveyness" and the lower levels are just not as interesting.
In particular, I don't want stupid untested typos in the commit history because they just aren't interesting or helpful.
But I'm willing to say that I'm probably missing something… I just don't see what it is yet. :-)
Those hidden, obsolete revisions are not shown on your DAG and they are generally not pushed nor pulled. In most respects they behave as if they were not even there. It is only when you need them that you can show them or go back to them (by using the --hidden flag of some of mercurial's command such as hg log or hg update). This gives you a nice safety net (since rewriting history is no longer a destructive operation) that you can use _if you want_. It also makes it possible to rewrite revisions that you have already shared with other users (since when you push a successor revision you also push the list of revisions that it is the successor of).
I think evolve is a significant step forward on the DVCS paradigm as it enables safe, distributed, collaborative history rewriting. This is something that, AFAIK, was not possible up until now.
http://git-scm.com/blog/2010/03/17/replace.html
It requires some manual setup on all checkouts for the changes to propagate automatically.
With Evolve, there is something similar to .git/refs/replace, called obsolescence markers, which may or may not indicate which commit replaces the obsolete commit (some commits are replaced, others are just pruned). These markers are created automatically every time you rewrite history. They don't have to be created manually like with git replace. Moreover, the obsolete commits are hidden from the UI unless you pass the --hidden argument to commands. Lastly, these obsolescence markers are propagated with push and pull operations. It doesn't seem to me like git replace can work over the wire?
I thought that being in the /refs/ namespace would make them eligible for easy synchronization once set up, but on second thought it doesn't seem like it. Git examines parents of refs to determine when something needs to be updated, but would use the parent of the object replacement in this case.
I think a mechanism similar to "git notes" would be better, where the ref points to a history of commits with each tree containing files for each replaced object. I've hacked git to do this at one point so we could retroactively edit git commit messages, but abandoned the effort after discovering "git notes".
Since it's really a commit that changes what history looks like, it's safe to push to other users.
More details here: http://mercurial.selenic.com/wiki/ChangesetEvolution
This isn't really a nitpick though, since this means that similar porcelain could be implemented on top of git fairly easily. The underlying data-model supports it.
Changeset evolution has some similarities with a distributed reflog. Like Git, commits are immutable in Mercurial and we can only "change" a commit by creating a new version and then hide the old version. Mercurial "hides" the old version today by stripping it from the repository — the old version is then stored in a bundle in the .hg/strip-backups folder.
This is far from optimal, so a first step was to add a concept of hidden commits. Hidden changesets have been part of core Mercurial for some time now. The evolve extension enables it and actually changes commands to use it. So "hg commit --amend" will normally strip the old commit, but when evolve is enabled, it will instead hide it. This is both faster and safer.
The next step is the introduction obsolete markers. These are small markers that tell you when a commit is succeeded by a better version. When you amend a commit, an obsolete marker will be created that say "the new version obsoleted the old version". This information is something that Git doesn't store, and it is by distributing these markers that we can make Mercurial more intelligent. As an example, if I amend a commit that you have already based work on, then evolve will know that it should rebase your work onto the successor I created. It will tell you about this when you pull from me and get the new version along with the obsolete marker. Your commits will be called "unstable" as that point, meaning that they are descendants of a commit marked obsolete (they descend from the commit I amended and thus marked obsolete). You can run "hg evolve" and it will figure out that it should run "hg rebase" behind the scenes.
Seen like this, I would say evolve is similar to what happens in Git when you edit history, but with some extra meta data that will allow you to edit shared history with confidence.