Changeset options (was Re: [PATCH]: Optional explanation for options)

[Michael Ellerman]

On Tue, 20 Sep 2005 14:47, Martin Pool wrote:
> Another approach, which lifeless has advocated, is to transmit the
> actual changes as a binary blob attached to the message, and a
> human-readable diff just as a summary.

We need a wiki page for IRC nick -> Real world name translations! :D

That's an interesting idea, I'm not sure if I like it or not. Another option 
would be to send a plain unified diff and then send just the meta-data as a 
blob, that'd make the blob smaller - but you lose some advantages as you're 
relying on the content of the diff.

I quite like John's changeset format, but it's still not quite stripped back 
enough for me. I'd like to see the following, although I admit it's a bit of 
a stretch, it's what peoples' scripts accept:

======== start of message
Change log here .. more change log, this all gets copied into the
commit change log. We can't have any guff in here.

---
diffstat

patch 

other gunk would be ok here

Writing a parser for that is a little difficult, as it's a bit hard to guess 
where the start of the change log is, and you wouldn't know it's a bzr cset 
until you get to the stuff at the bottom. But doable.

The binary blob option might strike a balance where we can have the diff being 
perfectly human readable and the blob vanishes for most people.

Having said that, there's still lots of grey-beards out there who think 
attachments are the devil's span - and sometimes I agree, and there are some 
lists that block attachments entirely.

Just as a data point, I got jk to have a quick look at the stats on the 
linuxppc64-dev patchwork database. The average patch size is 7K and the 
largest is 104K, the list doesn't accept anything > 120K or so.

If we bzip -9 | uuencode the 104K patch we end up with a 30K uuencoded blob, 
which is 493 lines long, or 368 lines if you wrap at 80 columns. That's going 
to look moderately horrible, but not too bad.

And there's always the possibility that the blob is not a diff at all, but 
some more compact format, eg. some type of weave annotation.

> I seem to recall people doing something like this with bk, but it does
> not seem common on the kernel archives (maybe because they disliked
> the attachments.)

I seem to recall that too, although I can't find any examples easily. People 
also sent so called BK PATCHes, which just had a changelog and a pointer to a 
tree. Hopefully we all agree that's broken, because it doesn't allow people 
to review the patch.
eg. http://www.cs.helsinki.fi/linux/linux-kernel/2002-51/0011.html)

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050920/1ae26060/attachment.pgp