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?

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.

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

From: "Jarkko Hietaniemi" <[email protected]>

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

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.

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

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

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

your work in stone to give other people solid foundation to build on.

I wasn't suggesting taking away the original SHA.

But to be honest, I wasn't expecting a miracle cure. I guess the core of my gripe is just that: how the commit message is part of the SHA. But that's part of the SHA and genome of git. In other words:
"sorry dude, you are out of luck".

Hi,

The commit message is not "part of the SHA" but it is part of the content that defines the SHA-1.

I guess in your case, you would rather have an empty commit message and attach the real message as a commit note.

Speaking for myself, I actually like it that the entire metadata is part of the commit object, even the commit message. It makes the whole thing more reliable: one cannot claim that the commit does one thing on one day, and the next day all of a sudden claim that the commit does something completely different. Git's just really consistent the way it is.

Ciao,
Johannes

Not that I expect anything to change.. but I'd like to point out again that I wasn't wishlisting "overwrite/replace/demolish the old commit message". More like a chain (hopefully of length one, but I canot
spll wuth a dam) of the messages, git log then showing the latest of them, but allowing accessing earlier ones.

Or another way to illustrate my idea: assume a create-once-no-delete filesystem.

echo 42 > the_answr.txt

Oh, darn it...

ln -s the_answr.txt the_answer.txt

Now both names still point to the content "42\n". The first SHA would be over ["42\n", "the_answr.txt"] and the second SHA over ["42\n", "the_answer.txt"].

But I get the distinct feeling of beating a poor dead horse here, so I'll shut up.

But you can't do that on a create-once filesystem; your symlink overwrites "the_answr.txt", which already exists. Obviously that is a technicality in the definition of "create-once", but if we take this as an analogy for a content-addressable object store, it is true. :) The name "answr.txt" in your case is really a sha1 "1234abcd", and we cannot create an object of that name that has anything _but_ the specific matching content in it. Your options are then:

- add a level of indirection; when we look up 1234abcd, show some other object instead (even though its content does not match 1234abcd). We have this already; it is the git-replace mechanism.

- during certain operations (e.g., showing the log), use 1234abcd as an index into another data store. We have this, too: git-notes.

I think I saw the objection elsewhere in the thread that these are not seamless to use. That is certainly true. Partially this is inherent (the client has to understand the extra object, and know when you want that object versus the original). But git could also improve its handling of these things.

For instance, we do not fetch notes from a remote by default. The big problems is that the refs/remotes hierarchy is set really set up only to hold branches, so we do not know where to put them. There was a discussion around the v1.8.0 time-frame about improving this[1], but it was never completed. That might be a productive direction if anyone is really interested in this topic.

-Peff

[1] I didn't re-read the old thread, but glancing through, this looks like a reasonable jumping-off point for reading:

http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165885