Mongrel2 is now officially on Github | Hacker News Reader

Mongrel2 is now officially on Github

github.com

29 pointsalexgartrell19 comments

The official blog post of why: http://news.ycombinator.com/item?id=2571499

Interestingly, things like this won't happen with the git repository model because it is persistent. New commits doesn't overwrite the old commits in the repo in any way, so you can always get back to a known state.

The only destructive packing operation takes great care in making sure it has stable storage before deleting stuff.

No, it doesn't save you from a dead disk, but at least you can at any time ask for the consistency of the repository.

And finally, it is good to see Zed learning from the experience :)

From reading the mailing list thread, he didn't lose committed work. He lost uncommitted work. He told fossil to revert everything. I have no dog in this hunt, but I think its important to read the mailing list thread. There you can see people asking if he lost committed vs. non-committed changes.

From this message, emphasis mine: http://www.mail-archive.com/fossil-users@lists.fossil-scm.or...

  fossil revert -- This is what destroyed my work.
  They were *uncommitted changes*, so once I did this 
  they were gone.  I didn't realize it'd nuke them 
  until it was too late.

Interesting. Because git doesn't protect you from that happening at all either :) It is a situation where shoot-yourself-in-foot is definitely possible.

hg does and I think git should do it as well. `hg revert file.py` creates a file.py.orig where file.py is being reverted. It does creates an extra file which you don't want but it's better in the cases where you accidentally reverted.

`hg purge` purges all files not tracked by mercurial and `hg rever --no-backup file.py` can be used when you don't want backup.

Considering its usefulness, I am happy to put up with untracked, original file it creates which I don't need most of the times; but boy is it a lifesaver when I do need it.

Wrong on both counts. Git's bizarre contrarian UI has screwed up many a repository. I can't tell you how many times some dude's weird "workflow" he decided was the best screwed everyone else on the project over.

In this case with fossil, the bug tied my hands so that the only way I could get the code back was to revert. It was a choice between trying to reverse engineer my original uncommitted work or revert and at least try to recover the repo. Since I don't work on more than one thing at once reverting was the best choice.

What do you mean by "persistent"? Unlike Git, in Fossil you cannot rewrite history _at all_. It's an immutable collection of artifacts. There's no rebase. See http://www.fossil-scm.org/index.html/doc/trunk/www/concepts....

Zed lost his working copy. You can do this in git by running "git reset --hard".

Or `git checkout file.py` for that sake. git should really create a file.py.orig like hg does or provide some alternate way to undo an incorrect checkout/reset.

git reset --hard will only orphan commits, they're still there. git reflog will get you to them fast and I'm sure there's many other more exotic ways to find them. Admittedly garbage collection will remove them at some point but that's generally a lot further away than 'oops'.

Working copy

You can't rewrite history in git either. You can however make new commits that are different from the old commits somehow. A branch in git is basically just a pointer to a set of immutable commits. http://hackerne.ws/item?id=2524993

It depends on what you mean by "history". Moving refs around is already "modifying history" in Fossil world.

I don't care what Fossil considers rewriting history. Rewriting history means altering a commit that has taken place in the past, which git can't do.

What about branches? Tags? Git's fast-forward?

Some people think of the whole DAG as history.

Branches and tags are just "Stick-it-notes" you attach to the DAG. They can be removed around at whim, but they only serve to mark a point in the DAG for your convenience. The GC process will kill parts of the DAG with no such branch/tag, but it only happens after some days by default.

Were git able to rewrite history, it couldn't use SHA1 checksums as names for the content. Note that a rebase alters the SHA1 stack you have, so it is regarded as something different. But you can't do that easily with published stuff as it would render further work impossible.

Fast forward is the recognition that a stick-it-note can be moved linearly ahead.

You won't be rewriting history, you will be writing new history and then forget about the old. But it is still there should accidents happen.

Branches and tags are just "Stick-it-notes" you attach to the DAG.

According to Git. And not if it's a tag object.

You won't be rewriting history, you will be writing new history and then forget about the old.

This is getting ridiculous. Next we'll be talking about parallel universes.

Zed's announcement http://twitter.com/#!/zedshaw/status/71988181616177152

If this was non-trivial its because Zed has been using Fossil SCM for his projects.

bloody hell, Zed beat me to the punchline in the first words of the announcement.

Well done all around.

Reply on news.ycombinator.com