"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > Junio C Hamano <junkio@xxxxxxx> wrote: >> + # This will barf when $theirs reach an object that >> + # we do not have in our repository. Otherwise, >> + # we already have everything the fetch would bring in. >> + git-rev-list --objects $theirs --not --all 2>/dev/null > > OK, I must be missing something here. > > That rev-list is going to print out the SHA-1s for the objects we > would have copied, but didn't, isn't it? So fetch--tool native-store > is going to get a whole lot of SHA-1s it doesn't want to see, right? True. We should send the standard output also to /dev/null. > Otherwise this is a nice trick. It doesn't assure us that after the > fetch those objects are still in the alternate. Meaning someone > could run prune in the alternate between the rev-list and the > native-store, and whack these objects. Given how small of a window > it is, and the improvements this brings to alternates, I say its > worth that small downside. Just don't prune while fetching. ;-) That is "don't prune after making an alternate that depends on you" in general. Without this patch, and without the keep (i.e. when the fetch is very small and the transfarred pack is given to unpack-objects) you would have depended on the alternates for those objects anyway. - 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