Mark Levedahl wrote:
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html