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

[Richard Stallman]

Thanks for those clear and concrete explanations.
I can now state my proposal very precisely.

    By now you've probably already guessed that we don't want merge commits
    whose ancestors would carry non-Free bits into our history.

We don't want them in our repository _carrying those ancestors_.
We don't want to do a merge that way.

But that doesn't mean we can't do a merge.

    You've probably also realized that we don't want pull --rebase either,
    for this would replay our local changes onto upstream's non-Free
    history.

We don't want a rebase to pull in those versions, but we may
still want to do a rebase.

    What we want is a rebase, but the other way round: we want to rebase
    upstream changes into our branch, so that we end up with:

      ab <- 17 <- 45 <- 62 <- b5

    where 62 is the rebased (possibly rewritten) c7, and b5 is the rebased
    (possibly rewritten) 67.

Sometimes we might want to do this, but it has the disadvantage of
reversing the direction of the arrows -- changing the structure of the
graph.

My proposal is to implement a modified pull.  We want it to do a
transformation that _conceptually_ applies to the whole repository,
but can be carried out revision by revision on new revisions being
pulled in.

In order to transform a revision, we must first have transformed its
ancestors.

Transforming a revision updates a correspondence table which maps
outside revision hash codes to transformed revision hash codes.  To
get the transformed version of an outside ancestor, you look up its
hash code in this correspondence table.  If it is not there, you
transform it so that it gets there.  Then you use the transformed
revision hash code from the table.

Naturally this recurses on the ancestors, but in normal use almost all
of them are already transformed.  It is only at the first pull
when our repository is empty that the process will be slow.

Once pull has been modified in this way, merge and rebase need
no change.

One advantage of this is that the structure of versions in our
repository will be isomorphic to the structure of versions
in Torvalds' repository.  The codes won't be the same, but it will
be easy to map them in either direction.

As a result, the same operation could be used to move revisions
from our repository to his repository.  It just needs to use the same
correspondence table in reverse.



We need one more feature that lets us specify where we want to alter
the code when transforming it.  Without this, transform would be a
no-op.

Here's a way to do this that also is a convenient way to do the
deblobbing.  We could have an operation, "transform revision X
replacing ancestor Y with Z."  If Y was the revision where a blob was
added, and Z was its parent without the blob, you can use it directly.
If the change in Y was more complex, you may need to make a new
revision derived from Y's parents, which contains the desired parts of
Y's changes but not the blob, and use that as Z.

Then you transform all the revisions you're interested in replacing Y
with Z.  Then you delete Y and its children before you post the
repository.

This could be packaged more conveniently with a replacement mapping,
Y1->Z1, Y2->Z2..., which could be stored in the repository so that
every subsequent transform operation in that repository knows about
it.


This operation is clean and general, so they might even install it.
It might have other uses too.


-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org