Re: documentation for committing with git - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: documentation for committing with git
Date
Msg-id AANLkTi=Sb4=LsiDK-Xn21C6n5i_L0kOVvdcXz7ThTQfV@mail.gmail.com
Whole thread Raw
In response to Re: documentation for committing with git  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: documentation for committing with git
Re: documentation for committing with git
List pgsql-hackers
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> All those issues can be avoided if you only run "git gc" when all the
> working directories are in a clean state, with no staged but uncommitted
> changes or other funny things. I can live with that gun tied to my ankle
> ;-).

Does even that open a possibility for data loss?

Use of the alternates feature will, to my knowledge, never write the
referenced repository: all new objects are held in the referencers.
The only condition as I understand it is not to generate garbage in
the reference repository, and that nominally does not happen in a repo
that exists only to be an object pool (you probably even want to use a
"bare" repository instead of one with checked out files).

I believe this feature is popular with hosting serving many repos of
the same project.

The especially paranoid may want to try setting their alternate,
referenced repository to be read-only with respect to the user doing
all the potentially-modifying work, undoing this if and when they feel
like adding more objects to the referenced repository. My guess is one
can do a clean checkout and then ride this strategy for quite a long
time (a year? more? it depends on how space-conscious one is), so that
would not be a incredibly onerous paranoia, if one has it.

fdr


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Using Small Size SSDs to improve performance?
Next
From: Tom Lane
Date:
Subject: Re: review: psql: edit function, show function commands patch