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

[Alexandre Oliva]

On Dec 30, 2010, Richard Stallman <address@hidden> wrote:

>     That could be done, I guess, but it would be way too cumbersome.
>     Cleaning up the repository is not something I'd like to have to do every
>     time some commit makes to some repository out there.

> So implement an optimized equivalent for that case.

That's what I'm trying to do.  Without breaking the git interface, while
at that.  http://thread.gmane.org/gmane.comp.version-control.git/164360
is where I discuss my proposal.

> Anyway, there is no need to do this "every time".
> I think once a day would be good enough.  Even once a week
> would be pretty good.

I think you don't understand how absurd what you're suggesting is,
because you probably have never used git.

Doing things the way you suggest means *anyone* who wanted to use our
repository, and also take changes from other repositories, would have to
run this incredibly expensive operation every time they wanted to run
the equivalent of “cvs update” to pick up changes from an upstream.
It's so absurd that I doubt anyone would want to do that.  I know I
wouldn't.  It's a non-starter.

> The method I just described is a way to merge changes from his tree to
> ours.

Well, you described a way to rewrite the commits of the repository.  In
git-speak, that's called rewriting history.  There's nothing 1984ish
about that, it just means you're modifying an earlier commit.

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.

That's why updating and merging across history rewrites is undesirable.

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.

I have a devised a much better plan.  It requires changes in git that I
believe will be useful to solve the very kind of rebase (and rewrite
history) problems that often give git users grief, so I expect it to be
welcome (unless my plan is flawed), and it shouldn't be hard to
implement.

So, unless you really want to understand the problem, which involves
learning about the inner data structures and common workflows of git, I
suggest you leave it at.

>> But it isn't our problem.  We can leave it to be implemented by
>> someone who wants it.

>     Well, *I* want it.  It won't be really useful for me otherwise.

> Could you explain why?  I don't see why you are concerned about
> merging changes automatically from our tree to his.

I'm more concerned about the opposite direction, that takes several
patches a day.  Being able to push our changes upstream is desirable,
but not a must.  However, it is an absolute must for any of us to be
able to trivially pull changes from upstream.  Actually, make that
upstreams, for any branch that tracks Linus' tree and has additional
patches might be desirable for any of us to merge into our personal or
published repositories.  If the Linux-libre repository doesn't fit into
people's regular workflow, there will be a strong incentive against
using it, against developing improvements for Linux on it.  It would be
self-defeating.  I don't want this kind of pain, not for myself, not for
other contributors.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer