"bzr commit" empty message error comes too late
Bug #207507 reported by
Stefan Monnier
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
Low
|
Paul Stewart |
Bug Description
Here is an example session:
% bzr commit -m ''
Committing to: /home/monnier/
modified lisp/simple.el
modified src/coding.c
modified src/data.c
modified src/indent.c
modified src/keyboard.c
modified src/keymap.c
bzr: ERROR: empty commit message specified
%
as you can see, the error message about the fact that the commit message is empty only comes at the very end. Much better would be to fail immediately. Believe or not, I "committed" my changes twice before noticing that they weren't being committed.
Related branches
lp:~paulbrianstewart/bzr/207507-bzr-commit-message
- Jelmer Vernooij (community): Approve
- Paul Stewart (community): Needs Resubmitting
-
Diff: 30 lines (+8/-2)2 files modifiedbzrlib/builtins.py (+4/-1)
bzrlib/tests/blackbox/test_commit.py (+4/-1)
Changed in bzr: | |
status: | Triaged → Confirmed |
Changed in bzr: | |
status: | Confirmed → In Progress |
Changed in bzr: | |
status: | In Progress → Confirmed |
Changed in bzr: | |
status: | Confirmed → Fix Committed |
Changed in bzr: | |
status: | Fix Committed → Fix Released |
milestone: | none → 2.5b1 |
Changed in bzr: | |
assignee: | nobody → Paul Stewart (paulbrianstewart) |
To post a comment you must log in.
On Thu, 2008-03-27 at 01:44 +0000, Stefan Monnier wrote: tmp/bzr/ work/
> Public bug reported:
>
> Here is an example session:
>
> % bzr commit -m ''
> Committing to: /home/monnier/
> modified lisp/simple.el
> modified src/coding.c
> modified src/data.c
> modified src/indent.c
> modified src/keyboard.c
> modified src/keymap.c
> bzr: ERROR: empty commit message specified
> %
>
> as you can see, the error message about the fact that the commit message
> is empty only comes at the very end. Much better would be to fail
> immediately. Believe or not, I "committed" my changes twice before
> noticing that they weren't being committed.
We check the message at the end because when it is being obtained
interactively, creating a complex message is something we shouldn't
force the user to do twice - *and* the prompt we give the user may
contain the actual diff being committed so the user can see what is
being recorded.
It is possible to special case this I guess, but I wonder if it
necessary.
-Rob www.robertcolli ns.net/ keys.txt>.
--
GPG key available at: <http://