Re: log format for vc-bzr

[Stephen J. Turnbull]

Eli Zaretskii writes:

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

Please don't.  Remember, the merge may have been interrupted due to a
conflict, and it is not complete until it has been resolved.  It's
possible that better terminology could have been chosen, but it
wasn't, and the bzr people are highly unlikely to change it now.

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

A word that I found in your post. ;-)  Probably came from Óscar.  It's
just a branch, which you have merged, but happens to have metadata you
don't want committed and pushed to the main repository.  The "micro"
doesn't have much meaning (except maybe "these commits are too small
in a semantic sense to be worth preserving in the official history").

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

Yes, that's close enough.  It "coalesces" one or more commits into a
single commit.

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

It forgets the whole series of commits, but only in the current
workspace.  The original commits (metadata) are still present in the
original workspace if you need them, I think.  (It depends on the
exact workflow, of course, but I think that's generally going to be
the case.)

Anyway, I thought that the point was that the commits were not "units
of work", but accidental stopping points like "went to lunch".  I
think it makes sense to collect those accidental stopping points into
the final commit, or perhaps into some intermediate commit.

 > Or am I missing something?

No, I don't think so, except that you seem to be looking for a way to
edit commit messages without changing the commit again, and for
various reasons, some plausible and some inertia on the part of the
developers, I don't think that's going to happen.