On 05/08/10 05:08, Daniel Farina wrote:
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
<heikki.linnakan...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
