Can't commit if there's nothing to commit [Pharo10]

[johnhwoods]

Which means, unlike in native git, you have to make a dummy change to a file to change the last commit message.

[astares]

Why commit, when there is nothing to commit?

If you want to change the commit message of a commit that has already been commited you have to rely on git itself:

https://linuxize.com/post/change-git-commit-message/#:~:text=To%20change%20the%20most%20recent%20commit%20message%2C%20use%20the%20git,of%20problems%20to%20your%20colleagues.

I would not offer it in Iceberg as once it is pushed it can have side effects (when others pull, ...)

[johnhwoods]

scenario - in Iceberg, make a commit. Spot a typo as it commits, the same way they magically appear when you press send on an email, comment on github issues, etc. Now, to fix that I have to go out of Smalltalk and do `git commit --amend -m "amended message"

Then presumably have to go back into Iceberg and repair-repository?

Surely nicer for Iceberg to say "no changes to commit, commit with new message?" Iceberg could even warn you from doing it after it has been pushed (which native git won't) so handling this not infrequent scenario in Iceberg is probably safer than kicking people out to git.

[daniels220]

I would say, equally common as noticing a typo in the commit message right after hitting commit, I notice a change that should have been part of that commit that I missed. So what I would really like is what SourceTree and other Git GUIs often have: an "amend last commit" checkbox just above the commit message field. When checked, this imports the last commit message into the field (allowing you to edit it, yes), but also allows you to stage further changes which will be included in the amended commit.

This might be more tricky with Iceberg, since we don't really use the git index the way it's "meant" to be used, and end up blowing away and re-writing whole packages, then staging-and-committing what the user checked in the UI. So we would probably have to read the last commit and explicitly make sure the changes it included are included in the new one, effectively re-implementing part of the logic of commit --amend. I don't think this would be too difficult though—all the hard work has already been done getting the commit logic working in the first place, I think.