Mark Levedahl wrote:
quoted text
> Johannes Schindelin wrote:
>
>>
>> Would it not be better to say explicitely which refs are expected to 
>> be present already (they start with "^" in the output of 
>> `git-rev-parse`, but you would need to do a bit more work, since you 
>> cannot just take the symbolic names).
>>
>> IMHO reliance on $(git fsck | grep ^missing) is not good. The file 
>> check might take very, very long, or use much memory. And you _can_ 
>> do better [*1*].
>>   
> Good idea, but I think it is simpler to just keep the ^... output from 
> git-rev-parse and check that those exist. What you suggest below seems 
> to presume all bases are themselves references, which is not the case 
> when doing, for example, master~10..master.
Examining further, I just don't know how to do this in shell. Basically, 
what I want is the list of parents of all bases, but those bases might 
not be explicitly mentioned, e.g., master --since=10.days.ago and I 
don't understand any direct plumbing call that will give me the list of 
parents in the general case. At the expense of extreme slowness I can do 
some of this invoking sort and uniq with long lists of objects. The pain 
in doing that on the sender side is definitely worth the potential gain 
on the receiver side (I now remember I tried that a while back, was able 
to do something reasonable in Python using sets, it died in bash).

Mark

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html