Re: [QUESTION] about .git/info/grafts file

From: Linus Torvalds <torvalds@osdl.org>
Date: Jan 19, 2006, 17:49 UTC
Message-ID: <Pine.LNX.4.64.0601190938110.3240@g5.osdl.org>
In-Reply-To: <cda58cb80601190933o4cedde92x@mail.gmail.com>

On Thu, 19 Jan 2006, Franck wrote:

Show 7 quoted lines

> 
> that would be great ! something like:
> 
>         git clone --since=v2.6.15 <src> <dst>
> 
> would be very useful for me. How would it work ? Does it automatically
> set up a graft file for me ?

I think we'd have to set up the grafts file, yes. However, it's actually less of an advantage than you'd think: especially for long development histories, the incremental packing is very very efficient. In contrast, if you only get recent versions, there's nothing to be incremental against, so the size of the pack will not be that much smaller.

So getting just a tenth of the development history will _not_ cause the pack to be just a tenth in size. It's probably closer to half the size of the full history.

Anyway, it's _conceptually_ something that git wouldn't have any problems with, but that doesn't mean that it's totally trivial either. The easiest way to do it (by far) would be to expand the native git protocol with a "get all objects of this one version" or something like that, and then you'd just do a "pull and mark all unknown commits in the grafts file".

So in effect, instead of getting the whole history pack, you'd get a pack that contains _one_ version (no history at all), and then (if you want to) you can get a pack that gets all stuff that isn't reachable from that one (ie "newer").

That would have the advantage that it's quite possible that many users might want to do just

	git clone --only=v2.6.15 <source> <target>

which would do that "one single version" variant of the clone. Then, later on, you could just do

	git pull --graft-unknown <source> <target>

to update the history.

Anybody want to try that? It would be a new command to "git-daemon" (instead of "git-upoload-pack", you'd do a new "git-upload-version" command internally: it would look a lot like upload-pack, and use the same unpacking protocol).

> but it's really a pain to run for example git-repack or git-prune commands.

Well, you really don't need to do that very often.

		Linus