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:
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
