Subject: using git-blame with patches as input

From: Don Zickus <[email-masked]>
Date: Mon, 16 Jun 2008 17:35:17 -0400

I deal with a lot of backported patches that are a combination of multiple
commits.  I was looking to develop a tool that would help me determine
which chunks of the patch are upstream (not necessarily currently in HEAD
but at some point in the file's history).

For example, if I took the top three commits from HEAD and appended them
into one patch file and then ran this tool with the patch as input, I
would hope that it gave as output the three original commits.

git-blame seem to handle a lot of the pieces I would need but my little
brain can't follow all the logic behind some of the mechanisms.

Seeing that git-blame can take patch chunks and traverse through commit
history to see if a particular chunk can be blamed on a parent, I feel
like I am most of the way there.  Unfortunately, I don't quite understand
some of the algorithms git-blame does when it splits the patch chunks into
smaller pieces to determine which pieces are blame-able on the parents.

Is there anyone who can help explain some of the low level logic to me?

What I would like to do is take a patch as input, split it into chunks and
traverse through the commit history looking for a match (or something of
high similarity) and output that commit id for each patch chunk.

git-cherry does something close but patches have to be exact whereas my
situation has a combination of patches.  I also understand there are
plenty of normal scenerios where my approach falls flat on its face (but I
have ideas for those).  I just wanted to get a simple common case going
first.

Thanks in advance.

Cheers,
Don