Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze

[Richard Stallman]

    > 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