documentation for committing with git
in [PgSql]
|
From: Daniel Farina on 4 Aug 2010 22:08 On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas <heikki.linnakangas(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 4 Aug 2010 23:03 On 08/04/2010 10:08 PM, Daniel Farina wrote: > On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas > <heikki.linnakangas(a)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). > > AIUI, git-new-workdir, which Heikki is proposing to use, does not work with bare clones. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 5 Aug 2010 05:35 On 04/08/10 16:50, Andrew Dunstan wrote: > On 08/04/2010 09:29 AM, Heikki Linnakangas 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 ;-). > > But to make sure of that I think you need to prevent git commands from > running gc automatically: > > git config gc.auto 0 > > or possibly > > git config --global gc.auto 0 > > And you'll need to make sure you run gc yourself from time to time. Good idea. I'll add that to the wiki. I don't like the automatic garbage collection anyway, it always kicks in when I'm doing something, and I end up interrupting it anyway. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 5 Aug 2010 05:43 On 05/08/10 05:08, Daniel Farina wrote: > On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas > <heikki.linnakangas(a)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. We're talking about different things again. I was talking about using one shared repository with multiple workdirs created with git-new-workdir. You're talking about anternates. What you say is correct for altrenates, and what I said about staged but not committed changes is correct for the multiple workdirs approach. BTW, "git gc" has a grace period, so that it won't delete any garbage newer than X days anyway. If I'm reading the git-gc man page correctly, that period is 2 weeks by default. That makes the possibility of accidentally deleting still-interesting staged but not committed changes quite small, even if you run "git gc" at a wrong time. You wouldn't normally have staged but not committed changes like that lying in backbranches for that long. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Pages: 1 2 3 4 5 Prev: Add column if not exists (CINE) Next: [HACKERS] need more ALTER TABLE guards for typed tables |