[PATCH]: Optional explanation for options

[Robey Pointer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 21 Sep 2005, at 21:40, John Arbash Meinel wrote:

> bzr cset ../other
>
> Should generate the changeset which lets you recreate "." from "../ 
> other".

Awesome!  I was always using it with no arguments, which apparently  
is the same as this way:

> bzr cset -r 25
> Just displays the current directories version 25 against it's ancestor
> (revno=24).

except always using the latest revision. :)  That's really cool that  
it already does exactly what you'd want when preparing to send a  
merge to someone.

> In general a changeset only makes sense when you compare against
> ancestry. So the idea is that if we have these trees:
>
> A - B - C - D - E - F - G
>           \
>             H - I - J
>
> If I want to send you G, the obvious changeset would be to send C->G
> (base=C, this=G).
> But since all I'm actually trying to do is to give you the contents of
> G, I can send J->G.
>
> Which would actually tell you what you would be merging into your  
> tree,
> rather than telling you what changes I have made. (say the changes  
> in E
> and F are (almost) identical to I, changing the base would mean you  
> need
> to look at less garbage in the diff).
>
> Now, we have been discussing some issues with the above. Namely  
> that it
> would be nice if changesets gave as much information as "bzr merge".
> Since bzr merge has access to the working trees, it can also pull  
> all of
> D, E, and F into the working branch. Which would mean that a changeset
> should bundle those revisions as well.
>
> The current code bundles enough information to regenerate the Revision
> XML, but not enough to generate all of the texts and inventories.
>
> Does that make more sense?

Yep!

I can (almost) imagine a situation where you'd want a changeset to  
have a collection of individual step-by-step patches in it, but the  
way I work, I'm always doing a quick temporary branch, adding some  
feature or fixing some bug, and then want to generate a single roll- 
up patch.

One thing I see just from playing around is that it takes the latest  
revision's commit message and elevates it to the top as a summary of  
the whole changeset.  It would be nice to be able to override that  
with -m (or -F) to provide a true summary, and include the latest  
revision info at the bottom with the rest.  Would that make sense?

robey

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iD8DBQFDM0npQQDkKvyJ6cMRAu3gAJ0bPz9nAwupULaWF02E3OQ70yJNjACfQYjj
kclRPwI1Id9RaH2IUcviVIM=
=zAcs
-----END PGP SIGNATURE-----