From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1233263396.4412.164.camel@goose.sun.com> References: <5d375e920901272106v77866afeua36bb6dc8b7feeca@mail.gmail.com> <5d375e920901290412k3e48d87dy5261c9b1f1681127@mail.gmail.com> <1233246631.4412.106.camel@goose.sun.com> <1233263396.4412.164.camel@goose.sun.com> Date: Thu, 29 Jan 2009 14:33:22 -0800 Message-ID: Subject: Re: [9fans] Sources Gone? From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 8eabb0e2-ead4-11e9-9d60-3106f5b1d025 On Thu, Jan 29, 2009 at 1:09 PM, Roman V. Shaposhnik wrote: > "trees" tend to be highly overloaded, but if you refer > to the filesystem hierarchy as seem by open, then the > above statement, if applied to Git, is misleading. What I mean is that if there is some file in the "repository" and I have a long-standing change to it (perhaps I have edited a template config file), the revision control systems tend to get annoyed that you're not checking that change back in. Mercurial, for instance, requires you to say -f on hg merge if you have pending changes. And I think that might even have disappeared in a recent version: you just can't merge anymore in an "unclean" repository. I am not talking about trees as trees of revision history; I just meant the local file system. I don't know how well Git handles this; I apologize for that. I think using venti as a backend for Git would buy you very little. Git already does a good job of managing its blocks. Russ