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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 7, 2015, 16:59 UTC
Message-ID: <xmqqd1yzyqzq.fsf@gitster.dls.corp.google.com>
In-Reply-To: <55C3FA66.90805@iki.fi>

Jarkko Hietaniemi <jhi@iki.fi> writes:

Show 12 quoted lines

> 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).