|From:||Alexandre Oliva <lxoliva-3d8yaqT+vUfYtjvyW6yDsg-AT-public.gmane.org>|
|Subject:||Re: The "Free" Kernel In Debian Squeeze|
|Date:||Thu, 30 Dec 2010 19:47:43 -0200|
On Dec 30, 2010, Richard Stallman <rms-mXXj517/zsQ@public.gmane.org> 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/16... 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
Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds