Re: log format for vc-bzr

[Eli Zaretskii]

> From: Juanma Barranquero <address@hidden>
> Date: Fri, 8 Jan 2010 11:28:08 +0100
> Cc: =?UTF-8?Q?=C3=93scar_Fuentes?= <address@hidden>, address@hidden
> 
> On Fri, Jan 8, 2010 at 10:00, Eli Zaretskii <address@hidden> wrote:
> 
> > As usual, the Bazaar documentation doesn't say anything about this
> > option that can be grokked by Bazaar non-experts.
> >
> >    --forget-merges
> >      Remove pending merge marker, without changing any files.
> >
> > What is a ``pending merge marker''?
> 
> After doing a merge to a branch, bzr status shows the pending merges:
> 
>   C:\emacs\trunk> bzr status
>   modified:
>     myfile.el
>   pending merge tips: (use -v to see all merge revisions)
>     Juanma Barranquero 2010-01-02 myfile.el: New file.
> 
> That means that the next commit will store the changes as a merge:
> "[merge]" will appear in the commit description, and you will be able
> to use log -n0 to see the history of the merge.

Thanks, but isn't this in the direction that is opposite of the one
for which it was suggested?  I though you are supposed to use it
_on_the_trunk_, after merging from a branch.  But you seem to show it
in the other direction, which confuses this issue even more, at least
for me.

> > And how removing it resolves the problem at hand?
> 
> "bzr revert --pending-merges" removes the info about the local changes
> being a merge. The working copy remains as it is (i.e, it includes all
> the changes from the merge), but Bazaar "forgets" that they came from
> a merge operation. The next commit will be a normal, non-merge commit.

So its effect is similar to that of rebasing?

> > And if this is the magic wand to leave personal
> > commit comments out of the public repository, then shouldn't we add
> > this to the recommended workflow on the wiki?
> 
> IIUC what Óscar was saying, he meant that --pending-merges can be used
> to sanitize a branch, by selectively copying and squashing commits
> from one branch into another before merging the changes back into the
> trunk.

But the issue at hand was how to hide personal comments in the commit
messages, not how to hide some of the intermediate changes.  Why would
I want to do the latter?