git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: integrity of a repository
Date: Sat, 15 Mar 2008 20:54:51 -0700	[thread overview]
Message-ID: <7v4pb7migk.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20080315132645.GC17579@ins.uni-bonn.de> (Ralf Wildenhues's message of "Sat, 15 Mar 2008 14:26:45 +0100")

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?
>
> For example, if I have a set of branches, create a file listing
>   branchname  sha-of-head
>
> for each such branch, and hash that file, and also 'git gc --prune',
> can I then be sure that not only does the repository contain exactly
> what I want (namely all history of all branches), but also that it does
> not contain any other material (say, stuff that may not be disclosed)?
>
> 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.

A freestanding git repository with a work tree consists of a set of refs
(that includes your local branches in refs/heads, tags in refs/tags, and
remote tracking branches refs/remotes but not limited to these three
categories.  Anything under refs/ is a ref by definition, and it includes
the stash), reflogs, the index, HEAD (which is typically a pointer into
refs/heads/ somewhere but can directly be pointing at a commit), and an
object store.  An object store of a repository that is not corrupt
contains all objects that are reachable from refs, reflogs, the index and
the HEAD, and "gc --prune" will remove everything else.

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.

  reply	other threads:[~2008-03-16  3:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-15 13:26 integrity of a repository Ralf Wildenhues
2008-03-16  3:54 ` Junio C Hamano [this message]
2008-03-16  6:32   ` Ralf Wildenhues
2008-03-16  7:01     ` Junio C Hamano
2008-03-16 10:09       ` Ralf Wildenhues

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v4pb7migk.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Ralf.Wildenhues@gmx.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).