[RFC] Amend commit messages

[timeless]

On Wed, Feb 23, 2011 at 3:36 PM, Laurens Holst <laurens.nospam at grauw.nl> wrote:
> Is it really so important to correct this kind of mistake?

Sadly, there are lots of tools deployed which are incredibly anal
about changeset messages and will refuse to allow things to get past a
certain point.

Unfortunately those tools aren't available to the poor developers
doing the actual work, who due to stress, etc. do make mistakes with
commit messages.

> But there is an answer. Rollback is super-easy. Just not after you’ve
> pushed.

Unfortunately you only find out that you messed up when someone else's
secret automated tool rejects your build deliverable. and their tool
isn't running server side, it's another client on another opaque box.

I'd definitely like to see something like this added. and while i'm
not always in favor of adding commits to the history, i'd actually
want this to be a commit because i'd want it to be
auditable/trackable.

I haven't looked carefully, but i'd like a requirement that a commit
can only modify changesets of which it is a descendent.

changeset: 3
parents: 1

changeset: 2
parents: 1

changeset: 1
parents: <null>

3 shouldn't be able to change 2.

It /might/ be nice to be able to change multiple changesets with a
single commit.
This isn't from the "i expect it to happen often case", it's more from
the "if i need to do cleanup, i'd love to be able to avoid adding lots
of changesets".

Lastly, it would be kind of neat if hg convert were able to fold the
final commit message into the original changeset - yes this will
change the hash of the commit, but convert often changes the hash
(e.g. if it filtered out a file).

Another problem with changesets is that managers sometimes change
their mind about what secret words should not be present.

DVCS makes appeasing managers painful. While you can go back and
rewrite the world, trying to redo merge commits just to get a secret
word removed from history is really painful. OTOH, if you could use
this tool, then convert, and then later publish the converted
repository, managers could be happy.

Yes, not everyone works in public all the time. A number of major
companies seem to favor "work in secret 10 months, publish 1 month"
(vacation 1 month?).