Re: [PATCH] built-in tar-tree and remote tar-tree

[Junio C Hamano <junkio@cox.net>]

Sven Ekman <svekman@yahoo.se> writes:

> Thanks for your answer. I'm looking forward to try the
> remote tar-tree at the weekend.

A word of caution.  This obviously needs the updated stuff on
both ends.  The downloader needs to have updated tar-tree, and
the other end needs the new command upload-tar.

> Is there a simple way to retrieve a single object or a
> list of objects _without_ any of their parents?

The thing is, I do not think that is what you really want.

If you do not have the necessary parents, many of the benefit
you list as "why do I want kernel from git repo" would not work.
The next fetch will try to see where the common ancestry commit
is, in order to download only from that one, for example. For
that you would need a well formed repositories on both ends.

Obviously bisect and anything that deal with the traversal of
ancestry chain would break, and while you would say "I accept
that some things may not work", their failure mode do not even
consider that the user might start from such an incomplete
repositories to begin with, so one thing is that the user would
be very confused, and another thing is that I would not be
surprised if some operations further "corrupt" such an already
incomplete repository (fsck, prune and probably bisect when it
tries to rewind the bisection branch -- your branch head may
point at nowhere and the user might need to do manual update-ref
instead of "git checkout master" to recover from it), causing
further grief.

In other words, to support such partial/incomplete repositories
properly, you are talking about a major major surgery.  I just
do not want to think about it right now.

On the other hand, the primary point of my patch is that the
result does _not_ pretend it is a proper git repository, so we
do not have to worry about all the above issues.