log format for vc-bzr

log format for vc-bzr

[Dan Nicolaescu]

The default C-x v l format for bzr does not show merges.

The default C-x v g format shows the version number from the merge:
Here's an example from bzr itself:


                  | from cStringIO import StringIO
0.16.5    aaron@a | import shutil
0.16.1    aaron@a | import sys
0.16.5    aaron@a | import tempfile
0.16.1    aaron@a | 
0.16.25   aaron@a | from bzrlib import (
                  |     builtins,
                  |     delta,
                  |     diff,
                  |     errors,
0.16.79   aaron@a |     osutils,
0.16.25   aaron@a |     patches,
0.16.74   aaron@a |     shelf,
0.16.72   aaron@a |     textfile,
0.16.54   aaron@a |     trace,
0.16.64   aaron@a |     ui,
0.16.102  aaron@a |     workingtree,

The result is that when using the "l" key binding in vc-annotate emacs
is not able to find the log for the revision mentioned in the annotate
buffer. 

This can be solved by passing the "--include-merges" to "bzr log".
Any reason not to do that?

Re: log format for vc-bzr

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> The default C-x v l format for bzr does not show merges.
>
> The default C-x v g format shows the version number from the merge:
> Here's an example from bzr itself:
>
>
>                   | from cStringIO import StringIO
> 0.16.5    aaron@a | import shutil
> 0.16.1    aaron@a | import sys
> 0.16.5    aaron@a | import tempfile
> 0.16.1    aaron@a | 
> 0.16.25   aaron@a | from bzrlib import (
>                   |     builtins,
>                   |     delta,
>                   |     diff,
>                   |     errors,
> 0.16.79   aaron@a |     osutils,
> 0.16.25   aaron@a |     patches,
> 0.16.74   aaron@a |     shelf,
> 0.16.72   aaron@a |     textfile,
> 0.16.54   aaron@a |     trace,
> 0.16.64   aaron@a |     ui,
> 0.16.102  aaron@a |     workingtree,
>
> The result is that when using the "l" key binding in vc-annotate emacs
> is not able to find the log for the revision mentioned in the annotate
> buffer. 
>
> This can be solved by passing the "--include-merges" to "bzr log".
> Any reason not to do that?

With the distributed development style that encourages committing often,
the history that comes from the merged branch can be very boring and
irrelevant. Something like this:

15.23 gone lunch
15.24 some refactoring
15.25 seems ready for testing

The important info is in the merge commit:

15 Added feature Foo

and that is what the log should show by default.

OTOH, for long-lived merged branches that implements complex features,
the merged history conveys useful information.

So, in the best Emacs tradition, both modes should be supported :-)

Personally, I'm against showing the merged history by default. If you
need to pass --include-merges for showing a merged commit, that's okay,
but not when the user asks for the log with C-x v l.

It would be interesting to have a method on the log buffer for showing
the merged history at some merge point. Some kind of "expand this one
level".

-- 
Óscar

Re: log format for vc-bzr

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> With the distributed development style that encourages committing often,
> the history that comes from the merged branch can be very boring and
> irrelevant. Something like this:
>
> 15.23 gone lunch
> 15.24 some refactoring
> 15.25 seems ready for testing

These are completely useless commit messages that should never occur in
a sane history.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: log format for vc-bzr

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> With the distributed development style that encourages committing often,
>> the history that comes from the merged branch can be very boring and
>> irrelevant. Something like this:
>>
>> 15.23 gone lunch
>> 15.24 some refactoring
>> 15.25 seems ready for testing
>
> These are completely useless commit messages that should never occur
> in a sane history.

Useless for whom? For the developer who is working on the feature? No,
they are small milestones and state-savers (for synchronizing his
desktop with his laptop, for instance). For the other developers? Yes,
but that's the reason why merged history is hidden by default.

Of course those example commits are intentionally chosen for making a
point. But the idea is: while you work on your personal branch, you
commit as you please; when you merge your changes, use a nice commit
message.

And finally, with a distributed workflow like the advocated on the wiki,
if you show the merged history on the log you will see a lot of
redundancy like this:

3324 Fixed bug #242
3324.1 Fixed bug #242

-- 
Óscar

Re: log format for vc-bzr

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Useless for whom? For the developer who is working on the feature? No,
> they are small milestones and state-savers (for synchronizing his
> desktop with his laptop, for instance). For the other developers? Yes,
> but that's the reason why merged history is hidden by default.

Such a useless commit history should never be published in the first
place.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: log format for vc-bzr

[Dan Nicolaescu]

Andreas Schwab <schwab@linux-m68k.org> writes:

  > Óscar Fuentes <ofv@wanadoo.es> writes:
  > 
  > > Useless for whom? For the developer who is working on the feature? No,
  > > they are small milestones and state-savers (for synchronizing his
  > > desktop with his laptop, for instance). For the other developers? Yes,
  > > but that's the reason why merged history is hidden by default.
  > 
  > Such a useless commit history should never be published in the first
  > place.

And to build on your argument: if the developer decides to put something
in a log, then it must be relevant, so we should show it by default.

Re: log format for vc-bzr

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>   > Óscar Fuentes <ofv@wanadoo.es> writes:
>   > 
>   > > Useless for whom? For the developer who is working on the feature? No,
>   > > they are small milestones and state-savers (for synchronizing his
>   > > desktop with his laptop, for instance). For the other developers? Yes,
>   > > but that's the reason why merged history is hidden by default.
>   > 
>   > Such a useless commit history should never be published in the first
>   > place.
>
> And to build on your argument: if the developer decides to put something
> in a log, then it must be relevant,

For who?

> so we should show it by default.

Okay, here is a more realistic log example. A user occassionally hacks
on Emacs for short periods and decided to implement a small feature:

1 created stubs for `foo' and `bar'. Call them from `zoo'.
2 merge from upstream.
3 implemented `foo'.
4 implemented `bar'.
5 implementation of `foo' was broken beyond hope. remove it.
6 merge from upstream.
7 `foo' implemeted, take two.
8 merge from upstream.
9 some code cleaning.
10 merge from upstream.

For the hacker which is working on that branch, this looks as a very
reasonable and informative history. But for the rest of us it is
uninteresting.

If you intend to set a policy that only changes which are relevant to
the general community enters the history of the *private* feature
branches of a given developer, or that the developer must remove the
local history before sending the change upstream... well, you are
throwing down the drain one of the most appreciated qualities of a dVCS:
to have a VCS for personal use with the ability of integrating the final
result into some other branch.

Using the dVCS will be painful but, hey, `log --include-merges' will
result on an impressive amount of information! :-) (Actually, under such
policy, `log --include-merges' will add no information at all, except
for the lon-lived branches of the kind of multi-tty, etc.)

-- 
Óscar

Re: log format for vc-bzr

[Jason Earl]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>   > Óscar Fuentes <ofv@wanadoo.es> writes:
>   > 
>   > > Useless for whom? For the developer who is working on the
>   > > feature? No, they are small milestones and state-savers (for
>   > > synchronizing his desktop with his laptop, for instance). For
>   > > the other developers? Yes, but that's the reason why merged
>   > > history is hidden by default.
>   > 
>   > Such a useless commit history should never be published in the
>   > first place.
>
> And to build on your argument: if the developer decides to put
> something in a log, then it must be relevant, so we should show it by
> default.

Really?  Perhaps I am just showing my ignorance, but I make trivial
commits all of the time with bzr.  As Óscar pointed out I will often
commit with a message like "Switching to main desktop" or "Time to go
home."  This might seem like junk (and it mostly is junk), but I have
surprised myself quite a few times by actually using these cues to
remember why it was that I left off where I did.

That doesn't mean that I want all of these commit messages to show up in
the log when I do bzr log on the mainline.  As a bzr user I personally
think that bzr has the right default in this case.  While working on a
feature or fixing a bug I can use the commit message to remind me what I
am doing.  When I finally merge, however, I need to create a commit
message that is more substantial.

I suppose that git users use rebase to erase all of the "junk" commit
messages.  From what I understand I can do the same with bzr.  However,
if I want to work on the same patch on more than one machine doing
things this way seems to raise the level of difficulty high enough that
I can't figure out how to do it :).

Now, obviously, you can write vc-mode so that it shows commit messages
that bzr log hides by default, but this will be quite surprising to
people that use bzr.

Jason

Re: log format for vc-bzr

[Stefan Monnier]

>> This can be solved by passing the "--include-merges" to "bzr log".
>> Any reason not to do that?

I agree we don't want that by default.

OTOH, vc-annotate should still do something useful.  I.e. either fetch
the missing log-info, or jump to the commit message of the
corresponding merge.

> It would be interesting to have a method on the log buffer for showing
> the merged history at some merge point.  Some kind of "expand this one
> level".

Yes, log-view-mode should be extended to provide such a facility.


        Stefan

Re: log format for vc-bzr

[Andreas Schwab]

Jason Earl <jearl@notengoamigos.org> writes:

> Really?  Perhaps I am just showing my ignorance, but I make trivial
> commits all of the time with bzr.  As Óscar pointed out I will often
> commit with a message like "Switching to main desktop" or "Time to go
> home."

There is nothing wrong with that, but do that only in your private local
branch and don't publish those junk commits.  They carry no value.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: log format for vc-bzr

[Stephen J. Turnbull]

Andreas Schwab writes:

 > There is nothing wrong with that, but do that only in your private
 > local branch and don't publish those junk commits.

That's easy to say, but frequent rebasing is not a desirable option in
bzr.  If the junk commits bother the community, then you should make
it an explicit policy that people simply should not make junk commits
in any branch that might eventually be pushed to the mainline.

The pipeline and loom plugins can help with this.

Re: log format for vc-bzr

[Stefan Monnier]

>> There is nothing wrong with that, but do that only in your private
>> local branch and don't publish those junk commits.

> That's easy to say, but frequent rebasing is not a desirable option in
> bzr.  If the junk commits bother the community, then you should make
> it an explicit policy that people simply should not make junk commits
> in any branch that might eventually be pushed to the mainline.

FWIW, I've been using two different VCS for the past many years: one for
my own local Emacs branch (was Arch and is now Bzr), and the other (CVS)
for the upstream.  That means I can't just push my changes upstream,
instead I have to copy patches "manually".

A friend recently asked me how I was "pushing" my changes and whether
switching to Bzr was done so that UI could do such "push" more easily,
and after thinking about it, I came to the conclusion that it probably
wouldn't change that much to my workflow: most of my local patches are
developped in a piecemeal fashion with lots of silly commits in
inconsistent states and many of them have been written years ago and
then regularly merged with upstream changes, so the history is
really messy.

Furthermore, this "copy the patch by hand" is usually not as simple as
it seems: very often I end up rewriting the whole change from scratch,
because in retrospect I see that it would be cleaner to do it some
other way.  I.e. the "commit" is an occasion for me to revisit my
change, clean it up, etc...

So I completely agree: such tiny changes are great for your proviate
branch, but you have to clean then up before you install them on
the trunk.  If you end up rebasing too often, it means your change is
old and it deserves taking a second look (e.g. to make sure it was kept
uptodate with other changes), so don't rebase too often: instead just
merge and know that when will come the time to install the change,
you'll have to recreate a clean history by hand.

The good thing about it is that the history you create doesn't have to
reflect the true history: it can be much cleaner, simpler, more linear.
You can create it specifically so that it is easy to understand.
This is in constrast to the real history of that changem which will
often involve trying a few different implementation strategies,


        Stefan

Re: log format for vc-bzr

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

> There is nothing wrong with that, but do that only in your private local
> branch and don't publish those junk commits.  They carry no value.

What about the example I posted before? With the recommended distributed
workflow, you are going to *double* the history length with redundant
entries:

1343 Fixed bug #2423  (merge)
1343.1 Fixed bug #2423 (original commit)

Isn't that junk?

And I insist on my question: if the history is useful to me, shall I
throw it away because it means nothing for others, so the next time
someone complains about a bug on that feature I lost the record about
the making of the feature?

If you set a policy forcing a CVS-like history, go ahead. Otherwise,
please don't worry about the usefulness of the history that comes from
other's merged changes, and which is hidden by default. Is as if you
want a carpet that is nicely crafted on both sides.

-- 
Óscar

Re: log format for vc-bzr

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> There is nothing wrong with that, but do that only in your private local
>> branch and don't publish those junk commits.  They carry no value.
>
> What about the example I posted before? With the recommended distributed
> workflow, you are going to *double* the history length with redundant
> entries:
>
> 1343 Fixed bug #2423  (merge)
> 1343.1 Fixed bug #2423 (original commit)
>
> Isn't that junk?

Yes, there is no value in a merge like this, it can just as well put
directly on the branch.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: log format for vc-bzr

[Óscar Fuentes]

Andreas Schwab <schwab@linux-m68k.org> writes:

>>> There is nothing wrong with that, but do that only in your private local
>>> branch and don't publish those junk commits.  They carry no value.
>>
>> What about the example I posted before? With the recommended distributed
>> workflow, you are going to *double* the history length with redundant
>> entries:
>>
>> 1343 Fixed bug #2423  (merge)
>> 1343.1 Fixed bug #2423 (original commit)
>>
>> Isn't that junk?
>
> Yes, there is no value in a merge like this, it can just as well put
> directly on the branch.

Well, we will see *lots* of history entries like that.

It is a byproduct of the distributed workflow. An insignificant one,
because you are not supposed to look into the merge histories of
microbranches. That's why bzr defaults to not showing merged histories.

The Emacs project is about producing a great piece of software, not
about producing a very nice VC log. If we have to introduce quite a bit
of junk into the *hidden* VC history of the project on exchange for a
better experience while developing the code, it is a good deal, IMO.

-- 
Óscar

Re: log format for vc-bzr

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> The Emacs project is about producing a great piece of software, not
> about producing a very nice VC log. If we have to introduce quite a bit
> of junk into the *hidden* VC history of the project on exchange for a
> better experience while developing the code, it is a good deal, IMO.

A commit message should describe the changes in the change set, not some
random external incident.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: log format for vc-bzr

[Stephen J. Turnbull]

Andreas Schwab writes:

 > A commit message should describe the changes in the change set, not some
 > random external incident.

Bazaar fans (and Mercurial fans, for that matter) do not consider
merges to be random external incidents.  They consider a merge to be a
very high level editing operation, which has implications for testing
and other aspects of the development process, and therefore should be
noted in the history.  Eg, you must run the system tests again, and
you should run the unit tests again, too, at least if there were
concurrent changes to a unit.  The merged code base is an untested
code base.

This is true in a rebase as well.  You still have to retest after a
rebase.  But because rebasing turns the merge into a fast-forward, the
merge turd goes away.

Re: log format for vc-bzr

[Andreas Schwab]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Bazaar fans (and Mercurial fans, for that matter) do not consider
> merges to be random external incidents.

I didn't mean that.  I meant commits that are just snapshots because
"gone lunch".  Those are good enough for your personal branch, but have
no place in a published history.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: log format for vc-bzr

[Stephen J. Turnbull]

Andreas Schwab writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > Bazaar fans (and Mercurial fans, for that matter) do not consider
 > > merges to be random external incidents.
 > 
 > I didn't mean that.

OK.  Please note that you were replying to a post which gave something
like

3. merge "Fix a typo"
    3.1 Fix a typo

as an example, and you apparently were saying that that merge is noise
that should not appear in the logs.

Re: log format for vc-bzr

[Thien-Thi Nguyen]

() Óscar Fuentes <ofv@wanadoo.es>
() Wed, 09 Dec 2009 23:34:01 +0100

   Well, we will see *lots* of history entries like that.

   It is a byproduct of the distributed workflow. An insignificant one,
   because you are not supposed to look into the merge histories of
   microbranches. That's why bzr defaults to not showing merged histories.

I would rather not discourage curiosity, but instead, bad manners.
Unrestrained publishing of personal junk is bad manners.

thi

Re: log format for vc-bzr

[Óscar Fuentes]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

>    Well, we will see *lots* of history entries like that.
>
>    It is a byproduct of the distributed workflow. An insignificant one,
>    because you are not supposed to look into the merge histories of
>    microbranches. That's why bzr defaults to not showing merged histories.
>
> I would rather not discourage curiosity, but instead, bad manners.
> Unrestrained publishing of personal junk is bad manners.

bzr revert --forget-merges

allows to commit into microbranches as one pleases and leave a nice
corpse afterwards.

-- 
Óscar

Re: log format for vc-bzr

[Thien-Thi Nguyen]

() Óscar Fuentes <ofv@wanadoo.es>
() Thu, 07 Jan 2010 22:47:01 +0100

   bzr revert --forget-merges

   allows to commit into microbranches as one pleases
   and leave a nice corpse afterwards.

Cool, thanks for the tip.

thi

Re: log format for vc-bzr

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Thu, 07 Jan 2010 22:47:01 +0100
> 
> Thien-Thi Nguyen <ttn@gnuvola.org> writes:
> 
> >    Well, we will see *lots* of history entries like that.
> >
> >    It is a byproduct of the distributed workflow. An insignificant one,
> >    because you are not supposed to look into the merge histories of
> >    microbranches. That's why bzr defaults to not showing merged histories.
> >
> > I would rather not discourage curiosity, but instead, bad manners.
> > Unrestrained publishing of personal junk is bad manners.
> 
> bzr revert --forget-merges
> 
> allows to commit into microbranches as one pleases and leave a nice
> corpse afterwards.

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''?  And how removing it resolves the
problem at hand?  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?

reversion revulsion [was: log format for vc-bzr]

[Thien-Thi Nguyen]

() Eli Zaretskii <eliz@gnu.org>
() Fri, 08 Jan 2010 11:00:15 +0200

   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''?  And how removing it
   resolves the problem at hand?  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?

I'm concerned that mis- (or any, actually) use of "bzr revert"
in trunk/ (as opposed to in quickfixes/) will do some damage
upstream, in the sense that any change that discards (shared)
history is an ugly mistake.

That's just from a correctness pov.  I dread the performance
implications of having to do (and possibly screwing up):

cd .../trunk                        # 0
bzr update                          # 1
bzr merge ../quickfixes             # 2
bzr commit                          # 3
bzr revert --forget-merges          # 4

IIUC step 3 publishes, as does step 4, defeating atomicity.

Really, i would be much happier to see "bzr revert" prohibited
entirely on <http://www.emacswiki.org/emacs/BzrForEmacsDevs>
or wherever such policy lives, and see local branch history
suppression effected in step 2 in the merge proper.  That is
where i want to express "merge quickfixes/ changes, allowing
manual editing of a new comment (log entry) seeded with the
log entries of the quickfixes/ changes, but in the end
*discarding* those log entries".

More succinctly: Can bzr do what "git merge --squash" does?

thi

Re: log format for vc-bzr

[Juanma Barranquero]

On Fri, Jan 8, 2010 at 10:00, Eli Zaretskii <eliz@gnu.org> 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.

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

> 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. That's not necessarily an easily automated process.

At some point, people has to try and learn, we cannot give everything
as recipes, because there's no one single good way to do it all. With
--pending-merges you can leave personal commit comments out, or
depending of the developer's habits, *all* the branch development
comments out. Imagine that the unicode-2 branch were merged with

   bzr merge ../unicode-2
   bzr revert --pending-merges
   bzr commit -m "Merge unicode-2 branch."

That's much less useful that the normal merge / commit, where the
history of the branch is accessible. So encouraging people to use
--pending-merges as a recipe is much worse than encouraging them to
just read the docs, try things and ask when they do not understand
something.

All this in my VHO, of course.

    Juanma

Re: log format for vc-bzr

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > bzr revert --forget-merges
 > > 
 > > allows to commit into microbranches as one pleases and leave a nice
 > > corpse afterwards.
 > 
 > 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''?

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

The "pending merge marker" is an internal variable that (1) acts as a
flag that there is a merge pending, so you will be warned if you try
to do something that would mess up the merge, and (2) records the
additional parent to record in the commit.

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

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

Re: reversion revulsion [was: log format for vc-bzr]

[Juanma Barranquero]

On Fri, Jan 8, 2010 at 11:09, Thien-Thi Nguyen <ttn@gnuvola.org> wrote:

> That's just from a correctness pov.  I dread the performance
> implications of having to do (and possibly screwing up):
>
> cd .../trunk                        # 0
> bzr update                          # 1
> bzr merge ../quickfixes             # 2
> bzr commit                          # 3
> bzr revert --forget-merges          # 4
>
> IIUC step 3 publishes, as does step 4, defeating atomicity.

What would #4 do?

    Juanma

Re: reversion revulsion [was: log format for vc-bzr]

[Óscar Fuentes]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

>    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''?  And how removing it
>    resolves the problem at hand?  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?
>
> I'm concerned that mis- (or any, actually) use of "bzr revert"
> in trunk/ (as opposed to in quickfixes/) will do some damage
> upstream, in the sense that any change that discards (shared)
> history is an ugly mistake.
>
> That's just from a correctness pov.  I dread the performance
> implications of having to do (and possibly screwing up):
>
> cd .../trunk                        # 0
> bzr update                          # 1
> bzr merge ../quickfixes             # 2
> bzr commit                          # 3
> bzr revert --forget-merges          # 4
>
> IIUC step 3 publishes, as does step 4, defeating atomicity.

Nope, you have steps 3 and 4 reversed.

`bzr revert' does not modify committed history. Maybe you are
confusing it with `bzr uncommit', which NEVER should be used in trunk/?

> Really, i would be much happier to see "bzr revert" prohibited
> entirely on <http://www.emacswiki.org/emacs/BzrForEmacsDevs>
> or wherever such policy lives, and see local branch history
> suppression effected in step 2 in the merge proper.  That is
> where i want to express "merge quickfixes/ changes, allowing
> manual editing of a new comment (log entry) seeded with the
> log entries of the quickfixes/ changes, but in the end
> *discarding* those log entries".
>
> More succinctly: Can bzr do what "git merge --squash" does?

From my careless reading of `git help merge', I think that

bzr merge <something>
bzr revert --forget-merges

does that, or something very similar.

-- 
Óscar Fuentes
Desarrollo de Software

Re: log format for vc-bzr

[Daniel Clemente]

El vie, ene 08 2010 a les 10:00, Eli Zaretskii va escriure:
> As usual, the Bazaar documentation doesn't say anything about this
> option that can be grokked by Bazaar non-experts.
>
  It does. See the 2 last paragraphs of bzr help revert:

,----
|   The working tree contains a list of pending merged revisions, which will
|   be included as parents in the next commit.  Normally, revert clears that
|   list as well as reverting the files.  If any files are specified, revert
|   leaves the pending merge list alone and reverts only the files.  Use "bzr
|   revert ." in the tree root to revert all files but keep the merge record,
|   and "bzr revert --forget-merges" to clear the pending merge list without
|   reverting any files.
|   
|   Using "bzr revert --forget-merges", it is possible to apply the changes
|   from an arbitrary merge as a single revision.  To do this, perform the
|   merge as desired.  Then doing revert with the "--forget-merges" option will
|   keep the content of the tree as it was, but it will clear the list of
|   pending merges.  The next commit will then contain all of the changes that
|   would have been in the merge, but without any mention of the other parent
|   revisions.  Because this technique forgets where these changes originated,
|   it may cause additional conflicts on later merges involving the source and
|   target branches.
`----

Re: log format for vc-bzr

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 8 Jan 2010 11:28:08 +0100
> Cc: =?UTF-8?Q?=C3=93scar_Fuentes?= <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> On Fri, Jan 8, 2010 at 10:00, Eli Zaretskii <eliz@gnu.org> 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?

Re: log format for vc-bzr

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>,
>     emacs-devel@gnu.org
> 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.

Re: log format for vc-bzr

[Juanma Barranquero]

On Fri, Jan 8, 2010 at 13:01, Eli Zaretskii <eliz@gnu.org> wrote:

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

I don't know what in my message (other than my usual clarity or lack
of it) makes you think that. I was talking about

   cd your-branch
   # hack hack hack
   bzr commit -m "..."
   cd ../trunk
   bzr merge ../your-branch
   bzr revert --pending-merges
   bzr commit -m "un-merged changes"

> So its effect is similar to that of rebasing?

Humm, no. Leaving aside uncommited changes, conflicts, etc., rebase
un-applies some commits, updates the branch, and reapplies these
commits as if they were new. "revert --pending-changes" is done on a
branch that has just been the target of a merge, and affects changes
that have not yet been committed.

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

Sorry, I don't follow what do you mean with "personal comments" vs.
"intermediate changes". I think Óscar meant that you have a branch
with several commits, some of them meaningful, some of them of the
"gone to lunch" variety, some reverting previous changes, etc., and
you can use merge (and in particular merge -c or merge -r) to move
commits to another branch, de-merge them (with revert
--forget-merges), fix them, and apply them to that new branch, so you
can reconstruct in the second branch a history of the first branch
totally to your liking (that including, of course, totally new commit
messages, and dropping the ones you don't like, or squashing several
original commits into one, splitting them, etc.). The result is
similar to what you could do in git with rebase (and rebase -i), but
less automatic.

    Juanma

Re: log format for vc-bzr

[Juanma Barranquero]

On Fri, Jan 8, 2010 at 13:20, Eli Zaretskii <eliz@gnu.org> wrote:

>> 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 history of a branch that gets committed with a merge; the history
you get with "log -n0" for merge commits.

> 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 you do merge followed by revert --pending-merges, yes. You can
selectively choose changes with "merge -c".

> "revert --forget-merges"
> forgets the whole commit, not just its commit message, so it seems to
> throw out the baby with the bathwater.

Again, it "forgets" the commits (in the original branch), but you
don't have to do it all at once.

    Juanma

Re: reversion revulsion [was: log format for vc-bzr]

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 08 Jan 2010 12:21:02 +0100
> 
> > cd .../trunk                        # 0
> > bzr update                          # 1
> > bzr merge ../quickfixes             # 2
> > bzr commit                          # 3
> > bzr revert --forget-merges          # 4
> >
> > IIUC step 3 publishes, as does step 4, defeating atomicity.
> 
> Nope, you have steps 3 and 4 reversed.

I usually do it slightly differently (following the wiki):

  cd ../trunk
  bzr update
  cd ../quickfixes
  bzr merge
  bzr commit

Where would I put "bzr revert --forget-merges" in my case? wouldn't
that be after the last "commit"?

> `bzr revert' does not modify committed history.

As far as I understood from Juanma and Stephen, it actually does.
Unless by ``committed history'' you mean something that excludes the
history of merging revisions between branch and trunk.  What am I
missing?

> Maybe you are
> confusing it with `bzr uncommit', which NEVER should be used in trunk/?

Not even if I need to revert the last commit?

Re: log format for vc-bzr

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 8 Jan 2010 13:24:29 +0100
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> On Fri, Jan 8, 2010 at 13:01, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > 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.
> 
> I don't know what in my message (other than my usual clarity or lack
> of it) makes you think that.

You ran "bzr status" in the trunk, that's why.  Sorry.

> > So its effect is similar to that of rebasing?
> 
> Humm, no. Leaving aside uncommited changes, conflicts, etc., rebase
> un-applies some commits, updates the branch, and reapplies these
> commits as if they were new. "revert --pending-changes" is done on a
> branch that has just been the target of a merge, and affects changes
> that have not yet been committed.

But isn't the effect on the resulting revision DAG very similar?

> > 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?
> 
> Sorry, I don't follow what do you mean with "personal comments" vs.
> "intermediate changes". I think Óscar meant that you have a branch
> with several commits, some of them meaningful, some of them of the
> "gone to lunch" variety, some reverting previous changes, etc.

Yes, I see that now, but if ttn called that ``personal junk'', then I
cannot disagree more.  That's the history of my work; I don't see how
someone could object to having it in the public repository.  Without
it, some changes, such as inadvertent merge mistakes, can never be
investigated and will remain a mystery forever.

I do understand that "revert --forget-merges" is one way of hiding
some of my changes from the public eye.  But I don't see any
compelling use-case for that, except some marginal situations.  OTOH,
my bzr experience with local branches is so short that my opinions
probably don't matter much. ;-)

Thanks.

Re: log format for vc-bzr

[Juanma Barranquero]

On Fri, Jan 8, 2010 at 13:52, Eli Zaretskii <eliz@gnu.org> wrote:

> You ran "bzr status" in the trunk, that's why.  Sorry.

Well, yes. After

   cd trunk
   bzr merge ../my-branch

it is "bzr status" in trunk which will show that there are pending merges.

(BTW, I just saw that I was able to mistype the name of
"--forget-merges" as "--pending-changes" and "--pending-merges" not
once, but several times. Ugh, sorry for adding to the confusion.)

> But isn't the effect on the resulting revision DAG very similar?

Bazaar's rebase doesn't "destroy" commits. If you have four, and
rebase, you still have four. If you then merge that branch back into
trunk, it will be one commit, with a "microbranch" showing four
commits. merge plus "revert --forget-merges" would allow you to change
these commits to your heart's content. git's rebase -i is more like
it, because you can rebase and merge commits (and, with a little more
effort, split them).

> Yes, I see that now, but if ttn called that ``personal junk'', then I
> cannot disagree more.  That's the history of my work; I don't see how
> someone could object to having it in the public repository.  Without
> it, some changes, such as inadvertent merge mistakes, can never be
> investigated and will remain a mystery forever.
>
> I do understand that "revert --forget-merges" is one way of hiding
> some of my changes from the public eye.  But I don't see any
> compelling use-case for that, except some marginal situations.

I think it depends on your style of development; certainly, even if
they are hidden into "log -n0" land, commits of the style "Go to
lunch", "Let's call it a day" and "OK, that's not too broken" do not
really add much value. As for other changes, some people like pushing
a clean history, some prefer to keep all the false starts and new
ideas and the like.

    Juanma

Re: reversion revulsion

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > cd .../trunk                        # 0
>> > bzr update                          # 1
>> > bzr merge ../quickfixes             # 2
>> > bzr commit                          # 3
>> > bzr revert --forget-merges          # 4
>> >
>> > IIUC step 3 publishes, as does step 4, defeating atomicity.
>> 
>> Nope, you have steps 3 and 4 reversed.
>
> I usually do it slightly differently (following the wiki):
>
>   cd ../trunk
>   bzr update
>   cd ../quickfixes
>   bzr merge
>   bzr commit

You can save the `cd's with

bzr update ../trunk
bzr merge
bzr commit

> Where would I put "bzr revert --forget-merges" in my case? wouldn't
> that be after the last "commit"?

You are doing something different from what we are discussing. We are
talking about not merging into upstream local revisions that adds
nothing interesting to the history. You are talking about getting the
latest changes from upstream and merging them into the quickfixes
branch. It is the opposite direction. You absolutely don't want to use
--forget-merges while merging upstream's changes into your branch,
because bzr would forget what revisions were already merged and try to
merge them again next time.

This brings another detail: if --forget-merges is used when you send the
changes from quickfixes to upstream via trunk, you need to reset the
quickfixes branch afterwards, because the next time you merge from
quickfixes it will include the previous revisions.

>> `bzr revert' does not modify committed history.
>
> As far as I understood from Juanma and Stephen, it actually does.
> Unless by ``committed history'' you mean something that excludes the
> history of merging revisions between branch and trunk.  What am I
> missing?

I'll rephrase: `bzr revert' does not modify history that already was
incorporated into the branch you are going to commit to. `revert'
operates on local uncommitted stuff.

>> Maybe you are
>> confusing it with `bzr uncommit', which NEVER should be used in trunk/?
>
> Not even if I need to revert the last commit?

No, because there is a race condition: someone can update from
upstream's trunk just before you execute the uncommit. To be sincere, I
don't know if bazaar is smart enough to realize that a revision was
removed from the remote branch and DTRT when people execute
`update'. Until this point is cleared, you'll better avoid `uncommit' on
trunk/ because if bzr does not the right thing, you can cause lots of
confusion.

-- 
Óscar

Re: reversion revulsion [was: log format for vc-bzr]

[Juanma Barranquero]

On Fri, Jan 8, 2010 at 13:36, Eli Zaretskii <eliz@gnu.org> wrote:

> I usually do it slightly differently (following the wiki):
>
>  cd ../trunk
>  bzr update
>  cd ../quickfixes
>  bzr merge
>  bzr commit
>
> Where would I put "bzr revert --forget-merges" in my case? wouldn't
> that be after the last "commit"?

Before the commit. "merge" brings changes from quickfixes into trunk,
and takes note that there was a merge. At that point, bzr status will
say so. If you do nothing more, commit will a the merge commit,
keeping the quickfixes history, and adding "[merge]" to the commit
log. If you do instead "revert --forget-merges", that metadata is
eliminated, and the next commit will be normal: no quickfixes history,
no "[merge]".

>> `bzr revert' does not modify committed history.

I hope it is now clear that it does not.

    Juanma

Re: reversion revulsion [was: log format for vc-bzr]

[Juanma Barranquero]

On Fri, Jan 8, 2010 at 14:29, Juanma Barranquero <lekktu@gmail.com> wrote:

> I hope it is now clear that it does not.

Sorry, I think I should read more slowly. Óscar is right, you're
talking about using --forget-merges in quickfixes, which is another
case altogether.

   Juanma

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.

Re: reversion revulsion

[Thien-Thi Nguyen]

() Juanma Barranquero <lekktu@gmail.com>
() Fri, 8 Jan 2010 11:53:40 +0100

   > That's just from a correctness pov.  I dread the performance
   > implications of having to do (and possibly screwing up):
   >
   > cd .../trunk                        # 0
   > bzr update                          # 1
   > bzr merge ../quickfixes             # 2
   > bzr commit                          # 3
   > bzr revert --forget-merges          # 4
   >
   > IIUC step 3 publishes, as does step 4, defeating atomicity.

   What would #4 do?

After reading your recent reply, i believe i have misunderstood
"bzr revert --forget-merges", which should be #3, bumping the
"bzr commit" rightly to #4.  In that case, there is no problem;
we get the equivalent (almost) to what "git merge --squash" does.
Cool.

I suppose from a policy pov, it would be good to distinguish
between "presentable" and "private" local-branch history, the
former being log entries written with publishing in mind.  In
that case, plain "bzr merge" seems to DTRT.

On the other hand, with private local-branch history (e.g.,
a series of log entries of the type "going to lunch", etc),
something like:

bzr-merge-squash () { bzr merge ;
  bzr log | grep INTERESTING-LOG-ENTRIES > LOG-ENTRY-INIT ;
  bzr revert --forget-merges ; }

is more suited (followed by "bzr commit -f LOG-ENTRY-INIT"),
and everyone defines INTERESTING-LOG-ENTRIES as they see fit.
Am i back on the right page now?

thi

Re: log format for vc-bzr

[Óscar Fuentes]

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

Re: log format for vc-bzr

[Andreas Schwab]

Juanma Barranquero <lekktu@gmail.com> writes:

> I think it depends on your style of development; certainly, even if
> they are hidden into "log -n0" land, commits of the style "Go to
> lunch", "Let's call it a day" and "OK, that's not too broken" do not
> really add much value. As for other changes, some people like pushing
> a clean history, some prefer to keep all the false starts and new
> ideas and the like.

Also, there is great value in trying to keep your changes bisectable.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: log format for vc-bzr

[Juanma Barranquero]

On Fri, Jan 8, 2010 at 14:50, Andreas Schwab <schwab@linux-m68k.org> wrote:

> Also, there is great value in trying to keep your changes bisectable.

Yes!

    Juanma

Re: reversion revulsion

[Juanma Barranquero]

On Fri, Jan 8, 2010 at 14:41, Thien-Thi Nguyen <ttn@gnuvola.org> wrote:

> bzr-merge-squash () { bzr merge ;
>  bzr log | grep INTERESTING-LOG-ENTRIES > LOG-ENTRY-INIT ;
>  bzr revert --forget-merges ; }
>
> is more suited (followed by "bzr commit -f LOG-ENTRY-INIT"),
> and everyone defines INTERESTING-LOG-ENTRIES as they see fit.
> Am i back on the right page now?

bzr log won't show anything different before and after the merge,
because a merge does not commit.

    Juanma

Re: log format for vc-bzr

[Thien-Thi Nguyen]

() Eli Zaretskii <eliz@gnu.org>
() Fri, 08 Jan 2010 14:52:54 +0200

   Yes, I see that now, but if ttn called that ``personal junk'',
   then I cannot disagree more.  That's the history of my work; I
   don't see how someone could object to having it in the public
   repository.  Without it, some changes, such as inadvertent
   merge mistakes, can never be investigated and will remain a
   mystery forever.

Although in personal projects i don't commit with the specific log
entry "gone to lunch", i *do* tend to make lots of small commits
with the pattern: open, futz, close.  E.g.:

 0 (open)  add debug output (printf, message, etc)
 1 (futz)  split func into producer + consumer; nfc
 2         make func take producer
 3         update func callers to pass producer
 4         add optional arg
 5         update docs
 6 (close) reindent caller-1 
 7         remove debug output

The end result of this series then is squashed into one commit
to the "trunk" (or whatever) as:

 8 Don't hardcode `func' producer; make callers pass it in.
   * src/file.ext (func) Take two more args: PRODUCER, OPTION.
   (caller-1, caller-2): Update calls to `func'.
   * doc/stuff.texi (API Infernals): Update `func' intro, docs.

I consider commits 0, 6 and 7 (open, close) to be ``personal
junk'' (ruminative, not so interesting, and potentially confusing
for ttn-in-six-months (weeks?, hours?)).  Commits 1-5, on the
other hand, are interesting, but are not of publishable quality
for two reasons: (a) they introduce inconsistent state -- 2
introduces arity mismatch; (b) their log entries are incomplete
(albeit useful to synthesize later).  I believe publishing those
as discrete commits would only add noise; they, too are ``personal
junk''.

Note that even though it is 8 that gets published, i can keep
0-7 in a local branch, untouched, for as long as i wish.  Now,
it's not just personal, it's perpetual!

Perhaps i should add that i don't find junk objectionable; what
conscious bit-recycler and occasional garbage collector would?

thi

Re: reversion revulsion

[Thien-Thi Nguyen]

() Juanma Barranquero <lekktu@gmail.com>
() Fri, 8 Jan 2010 15:32:58 +0100

   bzr log won't show anything different before and
   after the merge, because a merge does not commit.

You're right.  If i want the quickfixes/ history,
that means i need to be in that sub-directory.

thi

Re: log format for vc-bzr

[Eli Zaretskii]

> From: Daniel Clemente <dcl441-bugs@yahoo.com>
> Date: Fri, 08 Jan 2010 12:54:03 +0100
> 
> 
> El vie, ene 08 2010 a les 10:00, Eli Zaretskii va escriure:
> > As usual, the Bazaar documentation doesn't say anything about this
> > option that can be grokked by Bazaar non-experts.
> >
>   It does. See the 2 last paragraphs of bzr help revert:

Please give me some minimal benefit of a doubt.  I already read
all the docs on my machine that I found relevant, including
"bzr help revert".

First, what it says on my system does not include this part:

> |   Using "bzr revert --forget-merges", it is possible to apply the changes
> |   from an arbitrary merge as a single revision.  To do this, perform the
> |   merge as desired.  Then doing revert with the "--forget-merges" option will
> |   keep the content of the tree as it was, but it will clear the list of
> |   pending merges.  The next commit will then contain all of the changes that
> |   would have been in the merge, but without any mention of the other parent
> |   revisions.  Because this technique forgets where these changes originated,
> |   it may cause additional conflicts on later merges involving the source and
> |   target branches.

I use the latest stable release, 2.0.3.

More importantly, this addition, while it does help somewhat, still
falls short of making the effect clear.  What is a ``list of pending
merges''?  (This was already explained in this thread, but the docs
don't explain that.)  What are ``other parent revisions''?  Without
knowing that, it is impossible to understand the net effect this
command will produce.

Re: reversion revulsion

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 08 Jan 2010 14:27:46 +0100
> 
> You are doing something different from what we are discussing. We are
> talking about not merging into upstream local revisions that adds
> nothing interesting to the history. You are talking about getting the
> latest changes from upstream and merging them into the quickfixes
> branch.

No, I was talking about the same thing as you were, I am just confused
as to where the "revert --forget-merges" command should be run.  I
thought it should be run in the local branch, before merging it into
the trunk.  You seem to say that it should be run in the trunk _after_
merging the branch into it, is that right?

> This brings another detail: if --forget-merges is used when you send the
> changes from quickfixes to upstream via trunk, you need to reset the
> quickfixes branch afterwards, because the next time you merge from
> quickfixes it will include the previous revisions.

"Reset" how?  Shouldn't this be added to the wiki page?

Re: log format for vc-bzr

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 08 Jan 2010 14:48:30 +0100
> 
> 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.

Then the docs should have said "pending uncommitted merge results".

IOW, the fact that there should be a commit after the merge is not the
reason to call the just-performed merge "pending".  The results of the
merge are pending commit, but the merge itself is no longer pending,
it was already done.

Re: log format for vc-bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > 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.
>
> Then the docs should have said "pending uncommitted merge results".
>
> IOW, the fact that there should be a commit after the merge is not the
> reason to call the just-performed merge "pending".  The results of the
> merge are pending commit, but the merge itself is no longer pending,
> it was already done.

I disagree. The pending is not done until the corresponding revision is
created and hence integrated on the history of the branch. That revision
is the merge, not the source code changes that `bzr merge' created.

This is a about how to interpret certain terms. You are seeing the issue
from the POV of a code writer who cares mostly about the state of the
working tree. Me from the POV of somebody who is more fluent with the
tool (bzr) and see things on terms of history points.

-- 
Óscar

bzr Q&A [was Re: log format for vc-bzr]

[Glenn Morris]

Juanma Barranquero wrote:

> At some point, people has to try and learn, we cannot give everything
> as recipes, because there's no one single good way to do it all.

A "how to get started" document obviously shouldn't try to answer
every question anyone might ask.

But, I'm sure there is lots of useful information going to this list
now, I simply can't keep up with all these hundreds of emails about
bzr. I know people are asking questions that I'm probably going to be
asking, but first I need to figure out what to ask.

If someone(s) could start keeping a very simple, factual, plain-text
document that summarizes the things people have asked, along the lines
of:

Q: X asked, how do I do...
A: Y answered, use `bzr ...'

I for one would be very grateful, but I know it's a lot to ask.

Re: reversion revulsion

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> No, I was talking about the same thing as you were, I am just confused
> as to where the "revert --forget-merges" command should be run.  I
> thought it should be run in the local branch, before merging it into
> the trunk.  You seem to say that it should be run in the trunk _after_
> merging the branch into it, is that right?

Yes.

>> This brings another detail: if --forget-merges is used when you send the
>> changes from quickfixes to upstream via trunk, you need to reset the
>> quickfixes branch afterwards, because the next time you merge from
>> quickfixes it will include the previous revisions.
>
> "Reset" how?  Shouldn't this be added to the wiki page?

Reset here means to remove from quickfixes/ the changes you merged into
trunk/ applying --forget-merges before the commit. AFAIK, the most
simple way is to simply delete quickfixes/ and recreate it. Expensive, I
know. Another way is to use `bzr uncommit -r <something> && bzr revert'
where <something> is the right revision spec. Maybe it is too cumbersome
to use with the recommended distributed workflow.

--forget-merges works better with the "simulated git colocated branches"
that Juanma is using. There, you simply delete the branch once its
changes are integrated upstream.

-- 
Óscar

Re: log format for vc-bzr

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 08 Jan 2010 18:45:07 +0100
> 
> > Then the docs should have said "pending uncommitted merge results".
> >
> > IOW, the fact that there should be a commit after the merge is not the
> > reason to call the just-performed merge "pending".  The results of the
> > merge are pending commit, but the merge itself is no longer pending,
> > it was already done.
> 
> I disagree. The pending is not done until the corresponding revision is
> created and hence integrated on the history of the branch. That revision
> is the merge, not the source code changes that `bzr merge' created.
> 
> This is a about how to interpret certain terms. You are seeing the issue
> from the POV of a code writer who cares mostly about the state of the
> working tree. Me from the POV of somebody who is more fluent with the
> tool (bzr) and see things on terms of history points.

That's your mistake, right there: this is user documentation, not
documentation of bzr internals.  So it should take the POV of the user
who cares much less about the implementation than about the visible
effect.

It is this wrong POV that is one of the reasons that the current bzr
docs impose such a tremendous mental pressure on a novice who is
trying to make themselves fluent with the tool.

Re: log format for vc-bzr

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> It is this wrong POV that is one of the reasons that the current bzr
> docs impose such a tremendous mental pressure on a novice who is
> trying to make themselves fluent with the tool.

The "novice" is going to fail unless he has _some_ mental model of how
things work, and that mental model had better be something reasonably
close to how the actual tool works.

Dumbing-down documentation beyond a certain point simply leaves you with
useless documentation, not enlightened users...

-Miles

-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: log format for vc-bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> This is a about how to interpret certain terms. You are seeing the issue
>> from the POV of a code writer who cares mostly about the state of the
>> working tree. Me from the POV of somebody who is more fluent with the
>> tool (bzr) and see things on terms of history points.
>
> That's your mistake, right there: this is user documentation, not
> documentation of bzr internals.

Merge point is not about internal details. It is a fundamental concept
which the user is required to know if he pretends to make an effective
use of the DVCS.

[snip]

-- 
Óscar

Re: log format for vc-bzr

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Óscar Fuentes <ofv@wanadoo.es>,  emacs-devel@gnu.org
> Date: Sat, 09 Jan 2010 04:41:29 +0900
> 
> Dumbing-down documentation beyond a certain point simply leaves you with
> useless documentation, not enlightened users...

That's not what I said or asked for, and representing it like that is
cheap demagoguery.

Re: log format for vc-bzr

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 08 Jan 2010 21:46:55 +0100
> 
> > That's your mistake, right there: this is user documentation, not
> > documentation of bzr internals.
> 
> Merge point is not about internal details. It is a fundamental concept
> which the user is required to know if he pretends to make an effective
> use of the DVCS.

If it's such an important fundamental point, then why it is not
mentioned even once in the docs?  At least I couldn't find it.

Re: log format for vc-bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > That's your mistake, right there: this is user documentation, not
>> > documentation of bzr internals.
>> 
>> Merge point is not about internal details. It is a fundamental concept
>> which the user is required to know if he pretends to make an effective
>> use of the DVCS.
>
> If it's such an important fundamental point, then why it is not
> mentioned even once in the docs?  At least I couldn't find it.

IMHO, Bazaar docs are way too simplistic when explaining DVCS core
concepts, if they explain them at all.

-- 
Óscar

Re: log format for vc-bzr

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 08 Jan 2010 22:51:07 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > That's your mistake, right there: this is user documentation, not
> >> > documentation of bzr internals.
> >> 
> >> Merge point is not about internal details. It is a fundamental concept
> >> which the user is required to know if he pretends to make an effective
> >> use of the DVCS.
> >
> > If it's such an important fundamental point, then why it is not
> > mentioned even once in the docs?  At least I couldn't find it.
> 
> IMHO, Bazaar docs are way too simplistic when explaining DVCS core
> concepts, if they explain them at all.

I wasn't looking for explanation of core dVCS concepts.  I was looking
for the explanation of what "revert --forget-merges" does.  It could
have been explained without introducing the "merge point" concept.

But even if we accept that "merge points" must be understood for the
explanation of --forget-merges, the manual still shouldn't have used
"pending merges".  If a tool has a "merge" command, then a "merge" is
what that command does.  So talking about "pending merges" after a
merge was already done is simply bad didactically.  And the "merges"
part in --forget-merges is likewise a bad idea.  --forget-merge-points
might be a better one, because everyone will understand that a "merge
point" is not the same as "merge".

Re: log format for vc-bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar_Fuentes <ofv@wanadoo.es>
>> Date: Fri, 08 Jan 2010 22:51:07 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> > That's your mistake, right there: this is user documentation, not
>> >> > documentation of bzr internals.
>> >> 
>> >> Merge point is not about internal details. It is a fundamental concept
>> >> which the user is required to know if he pretends to make an effective
>> >> use of the DVCS.
>> >
>> > If it's such an important fundamental point, then why it is not
>> > mentioned even once in the docs?  At least I couldn't find it.
>> 
>> IMHO, Bazaar docs are way too simplistic when explaining DVCS core
>> concepts, if they explain them at all.
>
> I wasn't looking for explanation of core dVCS concepts.

Sorry, I thought that you asked why the bzr docs do not explain what a
merge point is.

> I was looking for the explanation of what "revert --forget-merges"
> does.  It could have been explained without introducing the "merge
> point" concept.

I don't think so.

> But even if we accept that "merge points" must be understood for the
> explanation of --forget-merges, the manual still shouldn't have used
> "pending merges".  If a tool has a "merge" command, then a "merge" is
> what that command does.  So talking about "pending merges" after a
> merge was already done is simply bad didactically.  And the "merges"
> part in --forget-merges is likewise a bad idea.  --forget-merge-points
> might be a better one, because everyone will understand that a "merge
> point" is not the same as "merge".

A "merge" is the abbreviated term for "merge point". It is a merge of
two branches.

At the time you use --forget-merges the merge point still doesn't
exist. It is created by the commit. So the hypothetical name for the
option would be more like

--commit-the-source-changes-but-do-not-create-a-merge-point

-- 
Óscar

Re: log format for vc-bzr

[Daniel Clemente]

>
> First, what it says on my system does not include this part:
> …

> I use the latest stable release, 2.0.3.
  I used the developent version (bzr branch lp:bzr); this must have been expanded.

>
> More importantly, this addition, while it does help somewhat, still
> falls short of making the effect clear.  What is a ``list of pending
> merges''?  (This was already explained in this thread, but the docs
> don't explain that.)  What are ``other parent revisions''?  Without
> knowing that, it is impossible to understand the net effect this
> command will produce.
> …

> (and further discussion)

Why not file Bazaar bugs about that? Documentation improvements are important for Bazaar.

Re: log format for vc-bzr

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> IMHO, Bazaar docs are way too simplistic when explaining DVCS core
> concepts, if they explain them at all.

I think it's a fundamental problem with the whole bzr project -- it
_seems_ like their original goal was svn-style "simple" user workflows,
hiding all the details, but then they tried to somehow mix in more
advanced DVCS functionality, and so far haven't done a very good job of
resolving the inevitable conflicts, or explaining to users how to
understand them.

[Git's approach, which is basically to expose the internal model fairly
early, and base a lot of the documentation around it, results in a
slightly steeper initial learning curve, but I think it also yields much
happier and more able users in the end.  Of course part of this is
because git has a very useful and understandable internal model.]

-Miles

-- 
Monday, n. In Christian countries, the day after the baseball game.

Re: log format for vc-bzr

[Thien-Thi Nguyen]

() Óscar Fuentes <ofv@wanadoo.es>
() Sat, 09 Jan 2010 00:05:51 +0100

   At the time you use --forget-merges the merge point still
   doesn't exist. It is created by the commit. So the hypothetical
   name for the option would be more like

   --commit-the-source-changes-but-do-not-create-a-merge-point

It sounds like the naming error (in the option) lies with the verb
"forget", which in the construction "forget X" implies X has already
happened.  If X is from the future, "don't bother to schedule X" is
better.

Another timing error is in the association of the option with the
command "revert", which also has strong (by definition!) implication of
undoing an action in the past.

Really, the distinction the option introduces is between the data
and the metadata.  A "bzr merge" combines both normally, and it is
there that the distinction (the message "combine only the data,
not the metadata") should be moved.  Concretely, the sequence:

  bzr merge
  bzr revert --forget-merges

would be better expressed as:

  bzr merge --data-only  ;; or somesuch

in order to avoid having to wrap one's head around "pre-forgetting".

thi

Re: log format for vc-bzr

[Andreas Schwab]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> It sounds like the naming error (in the option) lies with the verb
> "forget", which in the construction "forget X" implies X has already
> happened.  If X is from the future, "don't bother to schedule X" is
> better.

But the merge _has_ happend, it just hasn't been comitted yet (which is
always a separate step).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: log format for vc-bzr

[Eli Zaretskii]

> From: Daniel Clemente <dcl441-bugs@yahoo.com>
> Date: Sat, 09 Jan 2010 04:18:54 +0100
> 
> >
> > First, what it says on my system does not include this part:
> > …
> 
> > I use the latest stable release, 2.0.3.
>   I used the developent version (bzr branch lp:bzr); this must have been expanded.
> 
> >
> > More importantly, this addition, while it does help somewhat, still
> > falls short of making the effect clear.  What is a ``list of pending
> > merges''?  (This was already explained in this thread, but the docs
> > don't explain that.)  What are ``other parent revisions''?  Without
> > knowing that, it is impossible to understand the net effect this
> > command will produce.
> > …
> 
> > (and further discussion)
> 
> Why not file Bazaar bugs about that? Documentation improvements are important for Bazaar.

Done, bug #505093.

Re: bzr Q&A [was Re: log format for vc-bzr]

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  =?iso-8859-1?Q?=D3scar?= Fuentes
>  <ofv@wanadoo.es>,  emacs-devel@gnu.org
> Date: Fri, 08 Jan 2010 12:56:52 -0500
> 
> If someone(s) could start keeping a very simple, factual, plain-text
> document that summarizes the things people have asked, along the lines
> of:
> 
> Q: X asked, how do I do...
> A: Y answered, use `bzr ...'
> 
> I for one would be very grateful, but I know it's a lot to ask.

Not exactly in the format you asked for, but here's what I have so
far:

* Diff

** A handy alias for "bzr diff", put in [ALIASES] section of your
personal bazaar.conf file:

    diff=diff --diff-options -p

** To diff a branch against its parent:

    bzr diff -r submit:

** To diff the last revision [of foo] against the one before that:

    bzr diff -r-2.. [foo]

** To diff the last revision [of foo] against revision N:

    bzr diff -rN.. [foo]

* Status

** To show the files affected by the last revision:

     bzr status -V -r-2
 or
     bzr status -c-1

** To show the files affected between two revisions:

    bzr status -V -rN..M

* Revert, undelete, etc.

** To restore a deleted file FOO:

   bzr revert FOO

** To restore all deleted files:

   bzr revert `bzr deleted`

* Merge

** To merge from parent branch, even if there are uncommitted changes:

   bzr merge --force

** To start a branch from uncommitted changes in a trunk:

   cd ..
   bzr branch trunk fix-something
   cd fix-something
   bzr merge ../trunk --uncommitted
   cd ../trunk
   bzr revert
   cd ../fix-something
   [and hack in the branch]

Re: log format for vc-bzr

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: ofv@wanadoo.es,
>     emacs-devel@gnu.org
> Date: Fri, 08 Jan 2010 22:39:06 +0900
> 
> 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.

I filed a docs bug report about that.  If they won't change the
terminology, they should at least explain it in a clear manner.

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

No, I wasn't looking for ways of editing commit messages in this
thread.  That's another battle (that sounds like a lost one).  I
thought initially that ttn was after some semi-automated way of
cleansing commit messages when work on a feature is finished.  But
that thought was a mistake of mine.

Re: log format for vc-bzr

[Thien-Thi Nguyen]

() Andreas Schwab <schwab@linux-m68k.org>
() Sat, 09 Jan 2010 10:36:39 +0100

   > It sounds like the naming error (in the option) lies with the verb
   > "forget", which in the construction "forget X" implies X has already
   > happened.  If X is from the future, "don't bother to schedule X" is
   > better.

   But the merge _has_ happend, it just hasn't been comitted yet (which is
   always a separate step).

I conceptualize likewise, but something said up-thread gave me the
impression that in bzr terminology the commit delimits the "actual
merging" (or "merge point" or ...).

Regardless, hanging this off "bzr revert" is brain-damaged.

thi

bzr Q&A [was Re: log format for vc-bzr]

[Stephen J. Turnbull]

Glenn Morris writes:

 > If someone(s) could start keeping a very simple, factual, plain-text
 > document that summarizes the things people have asked, along the lines
 > of:
 > 
 > Q: X asked, how do I do...
 > A: Y answered, use `bzr ...'

Could the bug tracker be (ab)used to this end, maybe?

Or emacswiki.