Re: log format for vc-bzr

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <address@hidden>,
>     address@hidden
> Date: Fri, 08 Jan 2010 19:50:00 +0900
> 
> Eli Zaretskii writes:
> 
>  >     --forget-merges 
>  >       Remove pending merge marker, without changing any files.
>  > 
>  > What is a ``pending merge marker''?
> 
> A "pending merge" is a merge that you have started with "bzr merge"
> (or perhaps a "bzr pull" that resulted in a conflict) but not yet
> finished with "bzr commit".

Terrific!  So I just did a merge, but it is still considered
``pending''?  Who could have thought of a more confusing semantics??
(Please don't take this as aimed at you, Stephen; I will shortly say
the same on the Bazaar list.)

>  > And how removing it resolves the problem at hand?
> 
> By removing the pointer to the parents in the microbranch along with
> the merge marker, the history (metadata) recorded in the microbranch
> becomes inaccessible (in Lisp terms, garbage).

What is a microbranch?

> The "real" history (files changed by the merge operation) is not
> touched, and so the content changes, but not the historical
> metadata, is recorded in the upcoming commit.

So it's a way to pretend that a series of changes on a branch is a
single change that brings you to the last revision on that branch, is
that right?

If so, then I think it's not what I thought it would do.  This
sub-thread started from ttn's comment that "Unrestrained publishing of
personal junk is bad manners."  But ``personal junk'' can only be in
the commit messages, much less in the code.  (It could, of course,
happen that I somehow commit a version with lots of debug printouts or
some such, but how is that ``personal junk''?)  "revert --forget-merges"
forgets the whole commit, not just its commit message, so it seems to
throw out the baby with the bathwater.

Or am I missing something?

Anyway, thanks for the explanations.

>  > 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?
> 
> It's a wiki ....

Yes, but it states a policy, so I won't want to make such changes
unless they are agreed to.