On Mon, Nov 12, 2018 at 07:46:14AM -0800, Elijah Newren wrote: > So maybe my commit message should have been something > more like: > > """ > Knowing the original names (hashes) of commits can sometimes enable > post-filtering that would otherwise be difficult or impossible. In > particular, the desire to rewrite commit messages which refer to other > prior commits (on top of whatever other filtering is being done) is > very difficult without knowing the original names of each commit. > > In addition, knowing the original names (hashes) of blobs can allow > filtering by blob-id without requiring re-hashing the content of the > blob, and is thus useful as a small optimization. > > Once we add original ids for both commits and blobs, we may as well > add them for tags too for completeness. Perhaps someone will have a > use for them. > > This commit teaches a new --show-original-ids option to fast-export > which will make it add a 'original-oid <hash>' line to blob, commits, > and tags. It also teaches fast-import to parse (and ignore) such > lines. > """ > > ? Yes, that makes much more sense to me (though of course I've also been discussing it with you, so just about anything would at this point ;) ). It's possible that somebody would want to filter on tree id's, too. A fast-import stream just has trees incidentally as part of commit state, but we could say something like "by the way, this tree is X". You can even do "fast-export -t" to see subtrees, though I am not sure if that is intentional or just an artifact of being based on the diff code. I guess that is not all that useful, though. I was mostly thinking about it because of your "we may as well add them for tags too for completeness" above. But the issues around trees are sufficiently subtle that we're probably better off not trying to handle them here. There's a good chance we'd get it wrong, making our "let's just add this for completeness while we're here" totally backfire. -Peff
