Re: wishlist: make it possible to amend commit messages after push to remote

[Junio C Hamano <gitster@pobox.com>]

Jarkko Hietaniemi <jhi@iki.fi> writes:

> Not for the first time, and probably not for the last, I pushed a commit
> upstream without adding a link for the bug report as I was meaning to.
>
> Or it could have been...
>
> - Simple typos.
>
> - Broken URLs.
>
> - The following morning / 5 minutes / 5 second later thinking of
> an additional factoid that would've been great to have in the
> commit message.

Unfortunately (or fortunately, depending on your point of view),
these can only be avoided by being careful before you push things
out.  You need to learn to consider the act of publishing as casting
your work in stone to give other people solid foundation to build
on.

> - The impossibility of two consecutive commits referring to each other
> because the older one cannot know what the newer one will be called.

This is fundamental.  You shouldn't be able to "predict"; otherwise
the cryptographic protection of the history would not work.

> In general, I find the fact that once a commit has left the building,
> it goes into your permanent record, and cannot be changed, ever, to be
> very, very annoying. I get the cryptographic "sealing" with all the
> preceding changes, but...

If you really "get" it, you wouldn't be complaining about the
"impossibility" part ;-)

> Not that I've thought this through... but couldn't there be a bunch of
> "aliases" (new SHAs) for a commit?

You could filter-branch, after warning others that you will be
rewinding and rebuilding your history and disrupting their work
(and object replacement with "git replace" and the graft would
be good ways to help you during the filter-branch process, but these
shouldn't be used as a long-term mechanism---it will slow you and
more importantly others down unnecessarily and forever).