[Wish] commit --amend (aka. recommit, related to uncommit)

Bug #507529 reported by Martin von Gagern on 2010-01-14
140
This bug affects 27 people
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Unassigned
Breezy
Low
Jelmer Vernooij

Bug Description

I would wish for a feature similar to "git commit --amend".

The use of this would be twofold: to change (re-edit) a commit message, or to commit additional changes to the tree like added files or content modifications. Of course these two kinds of amendments (message and tree) might be used together.

Currently I fairly often do this:
1. make additional modifications to tree (if required)
2. bzr uncommit
3. bzr commit
4. paste old message from output of 1.
5. remove added indentation
6. edit message (if required) and save it

The "commit --amend" should work like the above, but should do steps 2 through 5 in one go, i.e. it should uncommit and then commit again, and when presenting an editor for the commit message, it should display the old commit message as a default. Giving the message on the command line should work as well, and simply replace the old commit message. Of course if the user were to cancel committing, e.g. by leaving an empty commit message, then the required uncommit probably shouldn't be done in the first place. Therefore the order should be "edit - uncommit - commit" or something equivalent.

I'd suggest "bzr commit --amend" in correspondence with git, and because most options applicable to a commit should work for this command as well. Of course, a new command (perhaps "bzr recommit" or "bzr amend") would be just as acceptable.

The same restrictions that apply to "uncommit", i.e. that removing revisions from a public branch is probably a bad idea, of course hold for amending as well. They haven't prevented uncommit from becoming part of the ui, so they are no reason against amending. Just like uncommit, amending the tip should leave a dead head in the repository. That's a feature, I believe.

Related branches

Martin von Gagern (gagern) wrote :

Oh, I forgot to mention: there was a discussion about a feature like this back in 2007:
http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/21558
or https://lists.ubuntu.com/archives/bazaar/2007q1/thread.html#21660
Some discussion, but not much in the way of results, and certainly no patch.

Martin Pool (mbp) on 2010-01-15
Changed in bzr:
status: New → Confirmed
importance: Undecided → Medium

Note discussion on Bug #329951

I would like this. I have a commit message that's a year old, and mentions fixing a bug number that doesn't exist (typo). I'd like to fix it so that VCS for bugzilla gets the right bug when it scans that commit.

Martin von Gagern (gagern) wrote :

Tom: If you noticed the typo right after the commit, then the hard uncommit & recommit workflow as outlined above would have solved the issue. If it's to late for that, then the request here won't help you either, as it really only requests a more ergonomical frontend to the above workflow.

You might want to have a look at bug #210142 instead, which seems better suited for situations like the one you describe.

Jelmer Vernooij (jelmer) on 2011-02-01
tags: added: commit
Jelmer Vernooij (jelmer) on 2017-06-23
Changed in brz:
status: New → Triaged
importance: Undecided → Low
Jelmer Vernooij (jelmer) on 2018-03-31
tags: added: git-world
Jelmer Vernooij (jelmer) on 2019-06-16
Changed in brz:
status: Triaged → In Progress
assignee: nobody → Jelmer Vernooij (jelmer)
milestone: none → 3.1.0
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers