Wrong commit message. What to do now?

Wrong commit message. What to do now?

[Karl Fogel]

I committed rev 100812 into trunk.  It's still fresh.  I accidentally
used the wrong log message -- the log message should have been:

  * lisp/bookmark.el (bookmark-show-annotation): Ensure annotations show,
    e.g. in Info bookmarks, by using `switch-to-buffer-other-window'.
    Patch by Thierry Volpiatto (Bug#6444).

The ChangeLog is correct; just the bzr commit message is wrong.  Does
anyone know if there's anything that can be done about this?  

Also, I had forgotten: are we not supposed to be committing to trunk
right now?

(Aside: it feels somewhat hard to be a drive-by maintainer these days,
which is what I am.  I try to be responsible about bookmark, saveplace,
and mail-hist stuff, but I can't follow project status in depth.  The
fact that trunk sometimes is, and sometimes is not, the right place to
push changes makes this role a bit more difficult.  Not unworkably
difficult, but it does lead to mistakes sometimes.)

-Karl

Re: Wrong commit message. What to do now?

[Óscar Fuentes]

Karl Fogel <kfogel@red-bean.com> writes:

[snip]

> The ChangeLog is correct; just the bzr commit message is wrong.  Does
> anyone know if there's anything that can be done about this?  

Aren't you the guy who work on the same office as the Bazaar hackers?

;-)

[snip]

Re: Wrong commit message. What to do now?

[Karl Fogel]

Óscar Fuentes <ofv@wanadoo.es> writes:
>> The ChangeLog is correct; just the bzr commit message is wrong.  Does
>> anyone know if there's anything that can be done about this?  
>
>Aren't you the guy who work on the same office as the Bazaar hackers?

:-)  No -- I don't now, but anyway I was never co-located with them.

I wish I knew how to solve this mis-message problem.  It's a pretty
important use case.

Re: Wrong commit message. What to do now?

[Óscar Fuentes]

Karl Fogel <kfogel@red-bean.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>>> The ChangeLog is correct; just the bzr commit message is wrong.  Does
>>> anyone know if there's anything that can be done about this?  
>>
>>Aren't you the guy who work on the same office as the Bazaar hackers?
>
> :-)  No -- I don't now, but anyway I was never co-located with them.
>
> I wish I knew how to solve this mis-message problem.  It's a pretty
> important use case.

Stefan asked for it on the bzr mailing list:

http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/39686

(click on the Subject for seeing all the thread)

IIRC it was filed in the "wishlist" category, "pie in the sky" priority :-)

Re: Wrong commit message. What to do now?

[Óscar Fuentes]

CC'ing emacs-devel

Karl Fogel <kfogel@red-bean.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>>Stefan asked for it on the bzr mailing list:
>>http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/39686
>>(click on the Subject for seeing all the thread)
>>IIRC it was filed in the "wishlist" category, "pie in the sky" priority :-)
>
> The two most recent revisions are still mine (the second-to-last one
> has the botched commit message).  I could 'bzr uncommit' them, fix, and
> recommit in order.
>
> But how would this play with everyone else who may have pulled changes
> from the trunk into their local branches already?

You would create some irritating problems for those. They need to notice
the problem (usually the next time the pull), figure out what is it, and
solve it. Possibly with bzr revert, or deleting `trunk' and cloning
again from upstream. Maybe the shared repository will save downloading
almost all of the revisions.

> That means I effectively can't uncommit, right?

You can't uncommit. The bzr repo at Savannah has a rule that forbids
that.

Re: Wrong commit message. What to do now?

[Stephen J. Turnbull]

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

 > >> The ChangeLog is correct; just the bzr commit message is wrong.  Does
 > >> anyone know if there's anything that can be done about this?  
 > >
 > >Aren't you the guy who work on the same office as the Bazaar hackers?
 > 
 > :-)  No -- I don't now, but anyway I was never co-located with them.
 > 
 > I wish I knew how to solve this mis-message problem.  It's a pretty
 > important use case.

Real solution requires changing Bazaar
--------------------------------------

Stefan has proposed (IIRC) a solution in which the commit message is
an annotation on the commit object, rather than part of the hashed
metadata that gives the commit its identity.  This fills me with
foreboding; I can expand on that, but it's "feelings" so this is not
the place.  It certainly is technically workable, and might even be
backward compatible with the right implementation.[1]

git uses a different method, adding a concept of "annotations to a
commit," which are not part of the commit's identity but are
automatically displayed by tools like "git log".  AIUI, this is
backward compatible, but old git versions can't see the annotations.
I suspect this would be fairly easy to implement in Bazaar, but I
don't know anything about the relevant internals.  I "like" this
approach better, but can't prove it.

Workarounds in Bazaar
---------------------

Empty commit with correct log message.  Do this on a branch if
necessary to associate it directly with the commit whose log needs
correction.  Append "(empty commit - correction of log message)" to
the log message.  If on a branch, the merge log message should be
"Correct log message of revid:stupid-bazaar-format-id-XXXXXXX."

Duplicate commit on a branch with correct log message.  This has the
potential to cause a conflict, but you'll probably get lucky.  Merge
with merge log message as above.

Tag the commit with "XXX-ignore-bogus-commit-log-use-ChangeLog" where
XXX is a uniquifier for this style of tag.

Suggested workflow changes
--------------------------

Don't use bound branches.

Always review log messages of commits you are about to push.

Use something like Didier Verna's patcher.el to ensure that all of the
work on a particular change is done consistently.


Footnotes: 
[1]  All the dodges I've thought of that make this possible are (a)
ugly and (b) mean that old Bazaar versions would not be able to
display log messages written by new Bazaar versions.

Re: Wrong commit message. What to do now?

[Karl Fogel]

Thanks, Stephen.  Considering the options, I guess I'll go with

  "Always review log messages of commits you are about to push."

...and just be more careful.  Subversion, though limited in other ways
of course, spoiled me in this respect, and I got used to being able to
un-shoot myself in the foot.

-Karl

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>Karl Fogel writes:
> > Óscar Fuentes <ofv@wanadoo.es> writes:
>
> > >> The ChangeLog is correct; just the bzr commit message is wrong.  Does
> > >> anyone know if there's anything that can be done about this?  
> > >
> > >Aren't you the guy who work on the same office as the Bazaar hackers?
> > 
> > :-)  No -- I don't now, but anyway I was never co-located with them.
> > 
> > I wish I knew how to solve this mis-message problem.  It's a pretty
> > important use case.
>
>Real solution requires changing Bazaar
>--------------------------------------
>
>Stefan has proposed (IIRC) a solution in which the commit message is
>an annotation on the commit object, rather than part of the hashed
>metadata that gives the commit its identity.  This fills me with
>foreboding; I can expand on that, but it's "feelings" so this is not
>the place.  It certainly is technically workable, and might even be
>backward compatible with the right implementation.[1]
>
>git uses a different method, adding a concept of "annotations to a
>commit," which are not part of the commit's identity but are
>automatically displayed by tools like "git log".  AIUI, this is
>backward compatible, but old git versions can't see the annotations.
>I suspect this would be fairly easy to implement in Bazaar, but I
>don't know anything about the relevant internals.  I "like" this
>approach better, but can't prove it.
>
>Workarounds in Bazaar
>---------------------
>
>Empty commit with correct log message.  Do this on a branch if
>necessary to associate it directly with the commit whose log needs
>correction.  Append "(empty commit - correction of log message)" to
>the log message.  If on a branch, the merge log message should be
>"Correct log message of revid:stupid-bazaar-format-id-XXXXXXX."
>
>Duplicate commit on a branch with correct log message.  This has the
>potential to cause a conflict, but you'll probably get lucky.  Merge
>with merge log message as above.
>
>Tag the commit with "XXX-ignore-bogus-commit-log-use-ChangeLog" where
>XXX is a uniquifier for this style of tag.
>
>Suggested workflow changes
>--------------------------
>
>Don't use bound branches.
>
>Always review log messages of commits you are about to push.
>
>Use something like Didier Verna's patcher.el to ensure that all of the
>work on a particular change is done consistently.
>
>
>Footnotes: 
>[1]  All the dodges I've thought of that make this possible are (a)
>ugly and (b) mean that old Bazaar versions would not be able to
>display log messages written by new Bazaar versions.

Re: Wrong commit message. What to do now?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Tue, 13 Jul 2010 18:16:45 -0400
> 
> Also, I had forgotten: are we not supposed to be committing to trunk
> right now?

Why not?  There's no branch or feature freeze anywhere in sight.

> (Aside: it feels somewhat hard to be a drive-by maintainer these days,
> which is what I am.  I try to be responsible about bookmark, saveplace,
> and mail-hist stuff, but I can't follow project status in depth.  The
> fact that trunk sometimes is, and sometimes is not, the right place to
> push changes makes this role a bit more difficult.  Not unworkably
> difficult, but it does lead to mistakes sometimes.)

If you commit a safe bugfix for a problem that exists in Emacs 23.2,
consider committing to the emacs-23 branch, not to the trunk; it will
get merged with the trunk later.  And there's a request from Stefan
and Yidong to commit either to the trunk or to emacs-23, but not to
both.  This is to make the merges from emacs-23 to the trunk a bit
less painful.  That's all, there are no other rules.  How's that too
complicated, I don't see.

Re: Wrong commit message. What to do now?

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>> Also, I had forgotten: are we not supposed to be committing to trunk
>> right now?
>
>Why not?  There's no branch or feature freeze anywhere in sight.

That's what I don't know how to tell -- where do I look to see what's
"in sight"?

In my previous mail, I listed the places I looked.  But in the past,
when there *has* been a feature freeze, I'm pretty sure those places
also did not say anything special.

>If you commit a safe bugfix for a problem that exists in Emacs 23.2,
>consider committing to the emacs-23 branch, not to the trunk; it will
>get merged with the trunk later.  And there's a request from Stefan
>and Yidong to commit either to the trunk or to emacs-23, but not to
>both.  This is to make the merges from emacs-23 to the trunk a bit
>less painful.  That's all, there are no other rules.  How's that too
>complicated, I don't see.

Oh, I wasn't saying that's too complicated.  What I was saying is that I
didn't know how to *find* those rules (and therefore, before this
moment, didn't know them).  

Now that you've stated them explicitly, I can refer to your mail.  I'd
been looking for them in places more permanent than the mail archive and
not finding them, that's all.

And for those of us who have only a little room left in our heads, we
can just remember "push only to trunk, always" if nothing else :-).

Thanks for laying it out clearly.

-Karl

Re: Wrong commit message. What to do now?

[Stefan Monnier]

> git uses a different method, adding a concept of "annotations to a
> commit," which are not part of the commit's identity but are
> automatically displayed by tools like "git log".  AIUI, this is
> backward compatible, but old git versions can't see the annotations.
> I suspect this would be fairly easy to implement in Bazaar, but I
> don't know anything about the relevant internals.  I "like" this
> approach better, but can't prove it.

This is the way Bzr will solve the problem, tho only once heel freezes
over (as opposed to the other solutions which Bzr wouldn't use even if
hell freezes over).
The main reasons to way for that fateful event is that they can't decide
of a way to keep track of those annotations which would be Right (IIRC,
the issue is that OT1H it needs to use a special format which should be
upgradable, but OTOH it needs to be user-visible since there might be
conflicts between different annotations coming from different branches).
So rather than being pragmatic, they prefer to wait until the
parallels meet at which point those tensions will finally disappear.


        Stefan