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

[David Jeske <jeske@google.com>]

On Tue, Jun 24, 2008 at 3:01 AM, Fedor Sergeev <Fedor.Sergeev@sun.com> wrote:
> 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)