> So, set it to ten years, and lose nothing of interest... Does that answer your objection?
No. It's still lossy. To turn the question around: if Subversion expired changesets after a given length of time, I think you would complain. Likewise, if git expired mainline commits after a certain length of time, you would also complain (I sure hope). git is lossy, and I happen to think that's entirely the wrong thing for a VCS to be. Making it "less" lossy is kind of like trying to keep your teenage daughter "less" pregnant.
> You could do that with git now. [Lengthy explanation follows]
I can also do that right now in Mercurial using the group extension (http://www.selenic.com/mercurial/wiki/index.cgi/GroupExtensi...), which is possible because Mercurial, being written in Python, is trivial to extend. But that's not the same as being part of the Mercurial workflow, any more than the bookmark extension in Mercurial prior to hg 1.1 counted as a real answer to git topic branches, or Loom counts as bzr's answer to Mercurial's mq now: it's not part of the VCS. Yes, I can make these all work however I wish--but as much as people have now forgotten, it's also relatively easy to make CVS and Subversion work in similar ways through tools such as Quilt (http://savannah.nongnu.org/projects/quilt), which allow for rebasing, offline commits, and many other features that you think of as git/hg/bzr-specific. We've abandoned those tools for good reasons: they required extensions, shell scripts, and odd workflows to work in distributed environments. We will do the same to our existing VCSes unless they can approach a more ideal workflow.
No. It's still lossy. To turn the question around: if Subversion expired changesets after a given length of time, I think you would complain. Likewise, if git expired mainline commits after a certain length of time, you would also complain (I sure hope). git is lossy, and I happen to think that's entirely the wrong thing for a VCS to be. Making it "less" lossy is kind of like trying to keep your teenage daughter "less" pregnant.
> You could do that with git now. [Lengthy explanation follows]
I can also do that right now in Mercurial using the group extension (http://www.selenic.com/mercurial/wiki/index.cgi/GroupExtensi...), which is possible because Mercurial, being written in Python, is trivial to extend. But that's not the same as being part of the Mercurial workflow, any more than the bookmark extension in Mercurial prior to hg 1.1 counted as a real answer to git topic branches, or Loom counts as bzr's answer to Mercurial's mq now: it's not part of the VCS. Yes, I can make these all work however I wish--but as much as people have now forgotten, it's also relatively easy to make CVS and Subversion work in similar ways through tools such as Quilt (http://savannah.nongnu.org/projects/quilt), which allow for rebasing, offline commits, and many other features that you think of as git/hg/bzr-specific. We've abandoned those tools for good reasons: they required extensions, shell scripts, and odd workflows to work in distributed environments. We will do the same to our existing VCSes unless they can approach a more ideal workflow.