Re: integrity of a repository

From: Ralf Wildenhues <ralf.wildenhues@gmx.de>
Date: Mar 16, 2008, 06:32 UTC
Message-ID: <20080316063215.GA6067@ins.uni-bonn.de>
In-Reply-To: <7v4pb7migk.fsf@gitster.siamese.dyndns.org>

Hello Junio,

* Junio C Hamano wrote on Sun, Mar 16, 2008 at 04:54:51AM CET:

Show 6 quoted lines

> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> 
> > I am aware that git provides integrity of a commit (and thus, a branch
> > head) via its sha, which covers both the tree and its history.
> >
> > But what about the integrity of a git repository as a whole?

[...]

Show 7 quoted lines

> > Would I need the in file listing all local and remote branches?
> > What about all heads in .git/*HEAD (such as FETCH_HEAD)?
> 
> That's an incoherent question ;-)  First you talk about snapshotting all
> the refs, as if you would want to make sure you can detect anybody moving
> the tips of branches after that happens, but then you talk about something
> completely unrelated.

Well, maybe they are two different parts of the larger question how one can fully characterize the state of a repository.

Show 8 quoted lines

> So the answer to the question in your later part of the message is that:
> 
>  - FETCH_HEAD, ORIG_HEAD and MERGE_HEAD do not protect anything from
>    getting pruned;
> 
>  - Objects that are not reachable from the tip of branches will remain in
>    the object store after pruning, if they are reachable from non-branch
>    refs (e.g. tags and the stash), reflogs, or the index.

OK. Now, is there a way to quickly ensure that a repository is in a pruned state, short of running 'git gc --prune'?

Thanks, Ralf