Messages in this thread | | | Date | Thu, 27 May 2004 07:51:27 -0700 | From | Larry McVoy <> | Subject | Re: [RFD] Explicitly documenting patch submission |
| |
On Thu, May 27, 2004 at 01:04:09AM -0700, Andrew Morton wrote: > Larry McVoy <lm@bitmover.com> wrote: > > > > I just read the whole thread and I can't help but wonder if you aren't > > trying to solve the 5% problem while avoiding the 95% problem. Right now, > > because of how patches are fanned in through maintainers, lots and lots > > of patches are going into the SCM system (BK and/or CVS since that is > > derived from BK) as authored by a handful of people. Just go look at > > the stats: http://linux.bkbits.net:8080/linux-2.5/stats?nav=index.html > > As productive as Andrew is I find it difficult to believe he has > > personally authored more than 5000 patches. He hasn't, he doesn't > > pretend to have done so but we are not getting the authorship right. > > Numerous people have asked Linus to make that small change to his scripts > but he prefers it the way it is, because the current practice better > represents how the patch got into the tree. The authors names are in the > changelog and the submitter's name is in the SCM metadata.
That means that all the SCM tools, BK, CVS, whatever, get the wrong attribution when you are trying to track down a bug. Which is more important when you are debugging: knowing who created the change or who pushed the change to Linus?
The high order bit, in my not humble opinion, is the author. If Linus wants to keep the info about the submitter then do that in the check in comments.
> A purist would say "that should have been a separate changeset" but I > disagree - I'd prefer that the patch which hits the tree is a single, > complete, logical whole. Because the quality and integrity of the > changeset is more important than precisely tracking the little fixes which > got added on the way through.
I think we can have our cake and eat it too, at least in BK (and there is no reason other systems couldn't do this as well): BK does not have the concept of a 1:1 binding between a change to a file and a changeset. A changeset is a container which may have one or more deltas to one or more files, i.e., it is many:1.
If you took to sending your patches as the original patch plus another patch, bundling them together (I can work out a format and GPLed tools for this) then what we could do is have the BK import tools record the first one as a set of deltas, the next one as another set of deltas, and so on. We can handle an arbitrary number of patches to patches to patches. Then when the import finishes we bundle up all the deltas in one logical changeset. 99% of the time people won't care about the details, when they are looking through the code the interfaces will all work as they do today, the BK/Web interface would export this as a patch just like you are used to, but when people do care the full information is there.
I suspect that with a little practice this could be quite useful. I could build tools which record the secondary patches as diffs to the patches (I think) and if you have ever read a diff of a diff it is suprisingly useful. I tend to save diffs of my work in progress and then later I'll generate diffs again and diff them to get my context back. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |