[PATCH]: Optional explanation for options

[John Arbash Meinel]

Robey Pointer wrote:
> 
> 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.

I'm glad you like it.

> 
...
>>> 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.

Sure. I think that is a common workflow. However, in general, the way
bzr works is that it wants to have the complete ancestry, so that in the
future if anyone (you) branched from an intermediate, things could be
tracked appropriately.

Now, I fully support rollup changesets and throwaway branches. In which
case the changeset should probably only install the final revision (and
not include the intermediate ones).

> 
> 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?

Well, yes and no. It would certainly be possible to allow -m and let you
specify a message. But after merging the changeset, this message would
never be recorded. (unless the person doing the merge copies it when
they commit).

The reason is that at the time *you* commit, a revision is created and
contains a message associated with it. The state corresponding to this
commit never changes. (we keep track of its hash to ensure its
validity). You could always add a new commit, with a new message instead.

If it's something you really want, it is easy to add. I'm just trying to
let you know what that will and won't change.

John
=:->


> 
> robey
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050922/5e2ec6d2/attachment.pgp