On Tue, 2007-08-28 at 06:06, Paul Mackerras wrote: > 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. 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 - 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
