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

Sven Ekman <svekman@yahoo.se> writes:

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.

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.