Re: why is git destructive by default? (i suggest it not be!)

From: David Jeske <jeske@google.com>
Date: Jun 24, 2008, 10:24 UTC
Message-ID: <e80d075a0806240324j79f872d3t1db9dfb87dc2d37c@mail.gmail.com>
In-Reply-To: <alpine.WNT.1.10.0806241343170.3824@theodor>

On Tue, Jun 24, 2008 at 3:01 AM, Fedor Sergeev <Fedor.Sergeev@sun.com> wrote:

Show 6 quoted lines

> It looks like you are severely restricting your own way of thinking about
> a source code management as a source code backup system only.
>
> While this might be a valid mindset for a gatekeeper on a public repository
> it way way restrictive for a developer that wants to have a system that
> helps him doing a job.

Odd. I've never been a gatekeeper. I'm just a developer who has burned himself enough times that I want a tool (i.e. source control) to help prevent me from ever destroying anything I create. I like that git is doing nicer things with merge tracking than older systems, and that it's easier for distributed teams to move changes around in more interesting ways than "up to the server" and "down from the server". However, I also want it to provide the guarantee that "if I don't touch the files in .git, it'll never lose my commits", which sadly isn't true by default. I'm glad I can easily change the GC policy, but I question why this isn't the default.

In another discussion about this, one of my coworkers pointed out that making the GC default "never" would be much safer for new users, and new users don't really need to worry about collecting things until their repositories get bigger anyhow.

I also think that it would be simpler to understand for everyone if every operation which can cause a dangling graph node require the exact same override method (i.e. -f is fine, the capitalization as in -d -> -D is fine, some --force or --hard is fine, but currently the system is using three different methods in three different places)