Re: log format for vc-bzr

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> 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??

bzr always requires to commit after a merge. That's why the merge is
"pending". Other tools, like git, does an implicit commit unless there
are conflicts.

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

I begun to use that term for short-lived branches where you usually
implement small features that requires just a few commits. For bzr it is
a branch as any other but, in practice, you may be interested on giving
a special treatment to it. We expect that branches that implement large
changes (like multy-tty, etc) shall be merged retaining history. For a
microbranch, that history may have little relevance and maybe it is
better to not incorporate it into upstream.

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

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?

--forget-merges forgets the revisions that lead to the final result, but
not the final result. You need to enter a commit message anyways.

As for the "personal junk", each one has its own opinion, as always. I
think that some revisions (or even the full series of revisions that
ended on something useful) can be considered junk (because they are
half-assed experiments, backups, etc). However, I think too that that
way of working allows people to left aside worries about "take care of
not breaking things" or "here I'll wish to save the current status of
the work, but then I'll have to think about a sensible commit message
for it". This is a matter of policy. If the agreement is that only "high
quality" revisions are allowed to be merged into upstream,
--forget-merges may be useful for some people.

[snip]

-- 
Óscar