Jon Smirl wrote: >> > 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. Or remembering to set --max-count or --max-age parameters to gitk (which are then passed to git-rev-list). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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