> So implement an optimized equivalent for that case. That's what I'm trying to do. Without breaking the git interface, while at that.
Given a clear picture of the job to be done, which I think I have stated, it should be fairly straightward to implement this case efficiently. Here's a suggestion. Maintain a table of the correspondence between version identifiers in Torvalds' repository and version identifiers in ours. To merge new versions, get the list of versions added to Torvalds' repository since a certain date, look for them in this table, and determine which are actually new. Topologically sort the new versions so that each one follows the one it was based on. Go down this list. For each version, fetch its diff against the version it was based on. Fetch our version corresponding to that one. Apply the diff. Commit it with the same message as the version in Torvalds' repository. Add the version identifier correspondence to the table. If the diff does not apply, that means there was a change in code we deleted. That requires manual attention. This ought to be fairly efficient. And the same program, plus a list of modifications to apply at certain versions, could do the original conversion. I don't know the git interface, and I don't know whether the goal of "not breaking it" is feasible. But I urge you not to worry about it too much. If you don't see how to implement that, implement the job regardless of the interface. Later you'll maybe see a way to get the interface right. The problem with that is that the commit id is a hash of the contents of the tree and of the ids of earlier commits. So when you change a commit, you invalidate all subsequent commits, that must be rebased on the new commit, and because the hashes involve the commit id of prior commits, the rebased commits will also get different ids, with nothing that relates them to the original commits. I agree that is a drawback, but this is still much better than the present situation. Creating a repository the way you suggest would make it very difficult for us (or anyone else) to bring in any changes that are later installed in Linus' tree, regardless of whether they need cleaning up. Not difficult at all -- I explained just above how to do it. Your other solution might be better, but please don't present this one out as worse than it is. -- Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org, www.gnu.org