Re: integrity of a repository

[Ralf Wildenhues <Ralf.Wildenhues@gmx.de>]

Hello Junio,

* Junio C Hamano wrote on Sun, Mar 16, 2008 at 04:54:51AM CET:
> 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?
[...]
> > 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.

> 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