views:

32

answers:

1

I've been using the SHA1 hashes of my commits as references in documentation, etc. I've realized that if I need to rewrite those commits, I'll need to create a lookup table to correspond the hashes for the original repo with the hashes for the filtered repo. Since these are effectively UUID's, a simple lookup table would do.

I think that it's relatively straightforward to write a script to do this during a filter-branch run; that's not really my question, though if there are some gotchas that make it complicated, I'd certainly like to hear about them. I'm really wondering if there are any tools that provide this functionality, or if there is some sort of convention on where to keep the lookup table/what to call it? I'd prefer not to do things in a completely idiosyncratic way.

+1  A: 

You could store the original hashes in commit messages, like git-svn does with revisions.

You could also use git-notes to annotate the new commits with their original hashes. Notes are stored in a special ref, refs/notes/commits. That means they will be outside of the annotated branch's history, but that gives you more freedom to change them.

Tobu
I think storing the hashes in the commit messages is the most appropriate solution.
intuited