> Here is another way to look at the shallow clone problem. The only > public ids in a git tree are the head and tag pointers. Send these to > the client. Now let's modify the git tools to fault the full objects > in one by one from the server whenever a git operation needs the > object. Dangling references would point to 'not-present' objects. Er... that would fault in a gigabyte the first time someone ran gitk, or several other history-browsing commands. Don't you need a way to say "tell the user this isn't present and will take an hour to download"?
gitk would need to be modified to only run enough of the commit tree to draw what is displayed in the window. As you page down it would retrive more commits if needed. There is no need for gitk to run 250K commits when I'm usually never going to look at them all. Of course this may mean some rework for gitk. -- Jon Smirl jonsmirl@xxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html