Re: documentation for committing with git
От | Daniel Farina |
---|---|
Тема | Re: documentation for committing with git |
Дата | |
Msg-id | AANLkTi=Sb4=LsiDK-Xn21C6n5i_L0kOVvdcXz7ThTQfV@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: documentation for committing with git (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: documentation for committing with git
Re: documentation for committing with git |
Список | 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 по дате отправления: