accept generated default commit message without asking
Bug #701668 reported by
Barry Warsaw
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
Medium
|
Unassigned | ||
Ubuntu Distributed Development |
Triaged
|
Undecided
|
Unassigned | ||
bzr-builddeb |
Invalid
|
Undecided
|
Unassigned |
Bug Description
When I'm using bzr to do UDD, and I make a change to the debian/changelog file, say with dch, bzr commit will copy the changelog entry into the commit message. This is great, except that if I just want to use the changelog entry exactly as given, bzr will complain that I haven't changed the commit message. This is true, but it's already fine. It would be nice if bzr commit had a command line option to suppress this complaint, or better yet, if it knew the changelog entry was fine and didn't complain at all.
Changed in bzr: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
tags: | added: commit |
summary: |
- bzr commit option for udd + accept generated default commit message without asking |
tags: | added: check-for-breezy |
To post a comment you must log in.
It seems to me the underlying thing here is not especially udd-specific: if the hook generates a suggested commit message, it's reasonable for the user to just accept it without modification. Generally speaking if they exit the editor without changing it, I think we should just accept it.
(That might mean changing the apis to distinguish between "a template the user can edit" and "a message the user can possibly edit or just accept", and I guess also "just use this without running the editor at all.")
I think the main question then is what the user will do if, once they get to the editor, they decide they don't want to commit after all. The options seem to be:
1- we request confirmation (maybe defaulting to yes) before committing
2- if you delete the whole contents of the file we check that's really what you mean before committing with an empty message
I guess we could later add options to control this.
I think 2 would probably be reasonable, though perhaps not super discoverable.