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

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 impossibility of two consecutive commits referring to each other
because the older one cannot know what the newer one will be called.

- The following morning / 5 minutes / 5 second later thinking of
an additional factoid that would've been great to have in the
commit message.

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

Not that I've thought this through... but couldn't there be a bunch of
"aliases" (new SHAs) for a commit?  The original one being the
"master", but as/if the commit message is changed, it could get new
SHAs.  Sort of separating the real data of the commit, and the metadata?

On Thu, Aug 06, 2015 at 08:23:02PM -0400, Jarkko Hietaniemi wrote:

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 impossibility of two consecutive commits referring to each other
because the older one cannot know what the newer one will be called.

- The following morning / 5 minutes / 5 second later thinking of
an additional factoid that would've been great to have in the
commit message.

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

Not that I've thought this through... but couldn't there be a bunch of
"aliases" (new SHAs) for a commit?  The original one being the
"master", but as/if the commit message is changed, it could get new
SHAs.  Sort of separating the real data of the commit, and the metadata?

There is something that solves at least part of this problem. It's
called git-notes[1]. This allows you to add notes to objects (ie,
commits) afterwards.

This can be used to attach additional information to a commit without
having to change the commit.

This obviously doesn't help for fixing typos in commits. There does
exist something that works likes you described called git-replace[2].
This allows you for example to replace any commit with any other commit.
For this to work with others, you have to make sure refs/replace/* is
being pushed, and is fetched by others. This can be done by setting up
refspecs, but it has to be done by everone who uses this repo.

One more thing, if you know that no one has fetched the branch you just
pushed yet, you can amend the commit and force-push it without any
problems (I'd sugget using --force-with-lease). 

Hope this helps, Kevin

[1]: http://jk.gs/git-notes.html
[2]: http://jk.gs/git-replace.html

Thanks (also to Jacob Keller), the git-notes might work in some cases.
But it's obviously a pasted-on solution, requiring a different usage,
e.g. "git log --notes", and whatever other UIs do with it.

One more thing, if you know that no one has fetched the branch you just
pushed yet, you can amend the commit and force-push it without any
problems (I'd sugget using --force-with-lease).

In my particular case, not going to work, multiple CI engines jump
hungry at every commit.

From: "Jarkko Hietaniemi" <redacted>

Thanks (also to Jacob Keller), the git-notes might work in some cases.
But it's obviously a pasted-on solution, requiring a different usage,
e.g. "git log --notes", and whatever other UIs do with it.

quoted

One more thing, if you know that no one has fetched the branch you 
just
pushed yet, you can amend the commit and force-push it without any
problems (I'd sugget using --force-with-lease).

In my particular case, not going to work, multiple CI engines jump
hungry at every commit.

Sound like you need an intermediate repo (similar in style to a personal 
github repo) between your personal machine and the CIs so that you get 
the chance to do those rebases/amendments, before you finally push to 
the CI.

It's almost the same human psychology issue as realizing what to do 
_after_ sending an email asking for help (and wanting to recall the 
email...).

To me, part of the sucess of a DVCS is having that extra layer where 
control has been distributed to you, rather than control still being 
with 'them'.

</bikeshedding>
--
Philip