On Sat, May 05, 2012 at 11:18:13AM -0500, Neal Kreitzinger wrote:
> What about this recipe:
>
> calculate sha1 of dirty deliverable (binary, html, etc)
>
> grep git tree objects for that sha1
>
> somehow determine which of the tree sha1's is newest. Not sure how
> to do that.
>
> grep commit objects for that tree sha1
>
> now you have the last commit containing that file so now you know the
> version of that file.
Your "not sure" step would be to walk the revision graph and look for
the tree in question. So really you would just walk and grep the trees.
If you know the filename (which you do in your instance), then it's not
even that expensive:
git rev-list HEAD |
while read commit; do
if test "`git rev-parse $commit:path/to/file`" = $sha1; then
echo "found it in $commit"
break
fi
done
But note that that does not tell you the revision of the whole project.
It tells you one _possible_ version, because it is one that contains
that file. If you remove the "break" there you can get the full set of
commits. And then you cross-reference that with the set of commits in
another file. And then another, and so on, until you eventually have
narrowed it down to a single commit.
It's kind of slow, mostly because we have to invoke rev-parse over and
over. But I don't think there is a way to print the sha1 of some path
for each revision via the regular revision walker.
You could probably do better by finding trees that contain a particular
sha1, then finding trees that contain that tree, and so forth, until you
have a set of commits that contain those trees. And then you could do
that backwards walk for all of the files in parallel (i.e., only accept
a tree if it matches all of the deliverables you have).
-Peff
--
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