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

From: Fedor Sergeev <fedor.sergeev@sun.com>
Date: Jun 24, 2008, 10:01 UTC
Message-ID: <alpine.WNT.1.10.0806241343170.3824@theodor>
In-Reply-To: <willow-jeske-01l5lTEoFEDjCVta@brm-avmta-1.central.sun.com>

On Tue, 24 Jun 2008, David Jeske wrote:

> This is mostly moot since I've understood that it's easy to set git to never
> GC. I guess I'm curious about why those GC fields would ever be set to anything
> other than never?

On Tue, 24 Jun 2008, David Jeske wrote:

Show 5 quoted lines

> My philosophy is simple, I never never
> never want to throw away changes, you shouldn't either. Disks are cheaper than
> programmer hours. I can understand wanting to keep things tidy, so I can
> understand ways to correct the 'easily visible changes', and also avoid pushing
> them to other trees, but I don't understand why git needs to delete things.

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. And, say, for me, for my own job, ability to experiment *safely* and effectively, ability to try out different histories is the most valuable asset that git brings to the world of SCMs.

My collegues that were forced to use Mercurial for their job are really unhappy about Mercurial's habbit of not modifying history at all. After a certain amount of time just looking at the history of an actively developed project causes a headache.

When you speak about allowing/disallowing destructive actions you actually speak about policies. Different organizations, different repositories have different policies. And git is very flexible in allowing you to implement all those different policies as you wish it.

And whether default policy should allow people to experiment freely or not is a very delicate question, which I would not really have enough courage to speculate on.

regards,
   Fedor.

P.S. Saying all that, I would really like to have an easy way to tie non-default policies to repositories so it propagates on clones. It is really helpful in big organizations. But thats another story.