Is there a fast and easy way to find out which of a set of SHA1 ids
refer to commits that (still) exist in a repository?

This is for use in gitk and there could be several ids, so I'd prefer
to avoid a fork/exec per id.  I could do a git cat-file -t $id for
each id, but that's a fork/exec per id.  git rev-parse doesn't check
whether an id actually refers to an existing commit, so it isn't the
answer.

What I want to be able to do is to cache the condensed topology
information that gitk uses for working out next/previous tags.  But
when I read in the cache I need to be able to know if the topology
includes commits that used to exist but have now been removed.  Hence
my question.

Thanks,
Paul.
-

[ message continues ]

Assuming you have a completely random set of ids, I think the easiest
way to do it would be to extend git-cat-file to accept several ids

I'm assuming you will still have to do git-rev-list to get the new commits
since the last known location of a branch head. If so, 
git rev-list <bogus-sha1>..<rewound-branch-tip> should be enough to
tell you you need to re-read that branch's entire history.

I just got up though, and since I don't drink coffee, waking up is a lengthy
process for me.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-

[ message continues ]

git rev-list has --stdin for specifying the commits. It will fail
the whole command if one of of them is invalid, though. The program
can be extended, possibly

-

[ message continues ]

Hmmmm.... I've occasionally wanted something similar, perhaps.

When one receives a git-generated patch, it has a bunch of
SHA1s in it, but those SHA1s all belong to individual files.
I've wanted to find a commit, perhaps the most recent, perhaps
the oldest, that still contains all of those blob SHA1s.
I _think_ any such commit is then going to allow the patch
to be applied without conflict, and would form "a correct"
starting point for a branch with the given patch applied.

Thoughts?  In the weeds?

Thanks,
jdl


-

[ message continues ]

Well, that is essentially "git am -3" does _without_ requiring a
single commit that has those blobs in the same commit.  As long
as the preimage blobs are found in your repository, it will
synthesize a tree that has them and applies the patch -- and
then it does a three-way merge between the result and the state
you originally tried to apply the patch to, using that
synthesized tree as the merge base.


-

[ message continues ]