Re: Tracking a repository for content instead of history

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 12, 2006, 22:25 UTC
Message-ID: <Pine.LNX.4.63.0612122316290.2807@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <fcaeb9bf0612121348q35549a4cof0adb85e0391b92c@mail.gmail.com>

Hi,

On Wed, 13 Dec 2006, Nguyen Thai Ngoc Duy wrote:

Show 9 quoted lines

> On 12/13/06, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > Hm.. I'm no git:// expert. But is it possible doing as follow?
> > 1. git-archive <base>
> > 2. reconstruct commit, blobs and trees from the archive
> > 3. tell git server that you have one commit, you need another commit
> > (maybe heads only, i'm not sure here)
> > 4. get the pack from git server, create new commit and a diff
> 
> Ok. Stupid idea. The pack may base on objects that I don't have.

The only not-so-brilliant idea is to reconstruct the commit from the archive. This is not possible, as not only some author and committer metadata is not reconstructable, but worse: the parents' hash is not either. And since all these are hashed to get the commit hash, you lost.

However, it could work like this:

- reconstruct tree commit
- ask for a diff between a certain commit, with respect to your tree

It might even be easy to convince git-upload-pack to construct a thin pack containing deltas _only_ against objects which are reachable from your tree.

Note: this is feasible, but not necessarily sensible:

- it puts more strain on the server, which otherwise could probably reuse 
a lot of deltas, and
- it contradicts the idea of _distributed_ development (for example, you 
could not tell which HEAD commit is newer when you fetched from two 
repos).

Probably, you could add a third argument: merges are not necessarily _possible_ with that setup. Note that this argument applies to shallow clones, too!

Ciao, Dscho