Re: documentation for committing with git

On 05/08/10 05:08, Daniel Farina wrote:
> On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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