{"thread":{"id":"40029","subject":"wishlist: make it possible to amend commit messages after push to remote","startedAt":"2015-08-07T00:23:02Z","lastAt":"2015-08-08T09:24:32Z","messageCount":9,"participants":["Jarkko Hietaniemi","Kevin Daudt","Junio C Hamano","Johannes Schindelin","Philip Oakley","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"267598","messageId":"55C3FA66.90805@iki.fi","threadId":"40029","inReplyTo":null,"subject":"wishlist: make it possible to amend commit messages after push to remote","fromName":"Jarkko Hietaniemi","fromEmail":"jhi@iki.fi","sentAt":"2015-08-07T00:23:02Z","receivedAt":"2015-08-07T00:23:02Z","isPatch":false,"sender":{"key":"jhi@iki.fi","avatar":null},"body":"Not for the first time, and probably not for the last, I pushed a commit\nupstream without adding a link for the bug report as I was meaning to.\n\nOr it could have been...\n\n- Simple typos.\n\n- Broken URLs.\n\n- The impossibility of two consecutive commits referring to each other\nbecause the older one cannot know what the newer one will be called.\n\n- The following morning / 5 minutes / 5 second later thinking of\nan additional factoid that would've been great to have in the\ncommit message.\n\nIn general, I find the fact that once a commit has left the building,\nit goes into your permanent record, and cannot be changed, ever, to be\nvery, very annoying. I get the cryptographic \"sealing\" with all the\npreceding changes, but...\n\nNot that I've thought this through... but couldn't there be a bunch of\n\"aliases\" (new SHAs) for a commit?  The original one being the\n\"master\", but as/if the commit message is changed, it could get new\nSHAs.  Sort of separating the real data of the commit, and the metadata?\n"},{"id":"267613","messageId":"20150807160924.GA4185@ikke.info","threadId":"40029","inReplyTo":"55C3FA66.90805@iki.fi","subject":"Re: wishlist: make it possible to amend commit messages after push to remote","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2015-08-07T16:09:24Z","receivedAt":"2015-08-07T16:09:24Z","isPatch":false,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Thu, Aug 06, 2015 at 08:23:02PM -0400, Jarkko Hietaniemi wrote:\n> Not for the first time, and probably not for the last, I pushed a commit\n> upstream without adding a link for the bug report as I was meaning to.\n> \n> Or it could have been...\n> \n> - Simple typos.\n> \n> - Broken URLs.\n> \n> - The impossibility of two consecutive commits referring to each other\n> because the older one cannot know what the newer one will be called.\n> \n> - The following morning / 5 minutes / 5 second later thinking of\n> an additional factoid that would've been great to have in the\n> commit message.\n> \n> In general, I find the fact that once a commit has left the building,\n> it goes into your permanent record, and cannot be changed, ever, to be\n> very, very annoying. I get the cryptographic \"sealing\" with all the\n> preceding changes, but...\n> \n> Not that I've thought this through... but couldn't there be a bunch of\n> \"aliases\" (new SHAs) for a commit?  The original one being the\n> \"master\", but as/if the commit message is changed, it could get new\n> SHAs.  Sort of separating the real data of the commit, and the metadata?\n> \n> \n\nThere is something that solves at least part of this problem. It's\ncalled git-notes[1]. This allows you to add notes to objects (ie,\ncommits) afterwards.\n\nThis can be used to attach additional information to a commit without\nhaving to change the commit.\n\nThis obviously doesn't help for fixing typos in commits. There does\nexist something that works likes you described called git-replace[2].\nThis allows you for example to replace any commit with any other commit.\nFor this to work with others, you have to make sure refs/replace/* is\nbeing pushed, and is fetched by others. This can be done by setting up\nrefspecs, but it has to be done by everone who uses this repo.\n\nOne more thing, if you know that no one has fetched the branch you just\npushed yet, you can amend the commit and force-push it without any\nproblems (I'd sugget using --force-with-lease). \n\nHope this helps, Kevin\n\n[1]: http://jk.gs/git-notes.html\n[2]: http://jk.gs/git-replace.html\n"},{"id":"267616","messageId":"xmqqd1yzyqzq.fsf@gitster.dls.corp.google.com","threadId":"40029","inReplyTo":"55C3FA66.90805@iki.fi","subject":"Re: wishlist: make it possible to amend commit messages after push to remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-08-07T16:59:05Z","receivedAt":"2015-08-07T16:59:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jarkko Hietaniemi <jhi@iki.fi> writes:\n\n> Not for the first time, and probably not for the last, I pushed a commit\n> upstream without adding a link for the bug report as I was meaning to.\n>\n> Or it could have been...\n>\n> - Simple typos.\n>\n> - Broken URLs.\n>\n> - The following morning / 5 minutes / 5 second later thinking of\n> an additional factoid that would've been great to have in the\n> commit message.\n\nUnfortunately (or fortunately, depending on your point of view),\nthese can only be avoided by being careful before you push things\nout.  You need to learn to consider the act of publishing as casting\nyour work in stone to give other people solid foundation to build\non.\n\n> - The impossibility of two consecutive commits referring to each other\n> because the older one cannot know what the newer one will be called.\n\nThis is fundamental.  You shouldn't be able to \"predict\"; otherwise\nthe cryptographic protection of the history would not work.\n\n> In general, I find the fact that once a commit has left the building,\n> it goes into your permanent record, and cannot be changed, ever, to be\n> very, very annoying. I get the cryptographic \"sealing\" with all the\n> preceding changes, but...\n\nIf you really \"get\" it, you wouldn't be complaining about the\n\"impossibility\" part ;-)\n\n> Not that I've thought this through... but couldn't there be a bunch of\n> \"aliases\" (new SHAs) for a commit?\n\nYou could filter-branch, after warning others that you will be\nrewinding and rebuilding your history and disrupting their work\n(and object replacement with \"git replace\" and the graft would\nbe good ways to help you during the filter-branch process, but these\nshouldn't be used as a long-term mechanism---it will slow you and\nmore importantly others down unnecessarily and forever).\n"},{"id":"267617","messageId":"55C4E67F.7050109@iki.fi","threadId":"40029","inReplyTo":"xmqqd1yzyqzq.fsf@gitster.dls.corp.google.com","subject":"Re: wishlist: make it possible to amend commit messages after push to remote","fromName":"Jarkko Hietaniemi","fromEmail":"jhi@iki.fi","sentAt":"2015-08-07T17:10:23Z","receivedAt":"2015-08-07T17:10:23Z","isPatch":false,"sender":{"key":"jhi@iki.fi","avatar":null},"body":"On Friday-201508-07 12:59, Junio C Hamano wrote:\n> You need to learn to consider the act of publishing as casting\nyour work in stone to give other people solid foundation to build\non.\n> ...\n> If you really \"get\" it, you wouldn't be complaining about the\n> \"impossibility\" part;-)\n\nI wasn't suggesting taking away the original SHA.\n\nBut to be honest, I wasn't expecting a miracle cure.  I guess the core\nof my gripe is just that: how the commit message is part of the SHA.\nBut that's part of the SHA and genome of git.  In other words:\n\"sorry dude, you are out of luck\".\n"},{"id":"267618","messageId":"55C4E77C.8070402@iki.fi","threadId":"40029","inReplyTo":"20150807160924.GA4185@ikke.info","subject":"Re: wishlist: make it possible to amend commit messages after push to remote","fromName":"Jarkko Hietaniemi","fromEmail":"jhi@iki.fi","sentAt":"2015-08-07T17:14:36Z","receivedAt":"2015-08-07T17:14:36Z","isPatch":false,"sender":{"key":"jhi@iki.fi","avatar":null},"body":"Thanks (also to Jacob Keller), the git-notes might work in some cases.\nBut it's obviously a pasted-on solution, requiring a different usage,\ne.g. \"git log --notes\", and whatever other UIs do with it.\n\n> One more thing, if you know that no one has fetched the branch you just\n> pushed yet, you can amend the commit and force-push it without any\n> problems (I'd sugget using --force-with-lease).\n\nIn my particular case, not going to work, multiple CI engines jump\nhungry at every commit.\n"},{"id":"267625","messageId":"a0b9f82a46f2887d3ff3fb392e2e4c2c@www.dscho.org","threadId":"40029","inReplyTo":"55C4E67F.7050109@iki.fi","subject":"Re: wishlist: make it possible to amend commit messages after push to remote","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-08-07T19:38:27Z","receivedAt":"2015-08-07T19:38:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn 2015-08-07 19:10, Jarkko Hietaniemi wrote:\n\n> But to be honest, I wasn't expecting a miracle cure.  I guess the core\n> of my gripe is just that: how the commit message is part of the SHA.\n\nThe commit message is not \"part of the SHA\" but it is part of the content that defines the SHA-1.\n\nI guess in your case, you would rather have an empty commit message and attach the real message as a commit note.\n\nSpeaking 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.\n\nCiao,\nJohannes\n"},{"id":"267633","messageId":"43BA4A09C14A43DEB23F4F14C2279A30@PhilipOakley","threadId":"40029","inReplyTo":"55C4E77C.8070402@iki.fi","subject":"Re: wishlist: make it possible to amend commit messages after push to remote","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2015-08-07T21:02:12Z","receivedAt":"2015-08-07T21:02:12Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jarkko Hietaniemi\" <jhi@iki.fi>\n> Thanks (also to Jacob Keller), the git-notes might work in some cases.\n> But it's obviously a pasted-on solution, requiring a different usage,\n> e.g. \"git log --notes\", and whatever other UIs do with it.\n>\n>> One more thing, if you know that no one has fetched the branch you \n>> just\n>> pushed yet, you can amend the commit and force-push it without any\n>> problems (I'd sugget using --force-with-lease).\n>\n> In my particular case, not going to work, multiple CI engines jump\n> hungry at every commit.\n\nSound like you need an intermediate repo (similar in style to a personal \ngithub repo) between your personal machine and the CIs so that you get \nthe chance to do those rebases/amendments, before you finally push to \nthe CI.\n\nIt's almost the same human psychology issue as realizing what to do \n_after_ sending an email asking for help (and wanting to recall the \nemail...).\n\nTo me, part of the sucess of a DVCS is having that extra layer where \ncontrol has been distributed to you, rather than control still being \nwith 'them'.\n\n</bikeshedding>\n--\nPhilip \n"},{"id":"267642","messageId":"55C5364C.6040904@iki.fi","threadId":"40029","inReplyTo":"a0b9f82a46f2887d3ff3fb392e2e4c2c@www.dscho.org","subject":"Re: wishlist: make it possible to amend commit messages after push to remote","fromName":"Jarkko Hietaniemi","fromEmail":"jhi@iki.fi","sentAt":"2015-08-07T22:50:52Z","receivedAt":"2015-08-07T22:50:52Z","isPatch":false,"sender":{"key":"jhi@iki.fi","avatar":null},"body":"On Friday-201508-07 15:38, Johannes Schindelin wrote:\n> 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.\n\nNot that I expect anything to change.. but I'd like to point out again \nthat I wasn't wishlisting \"overwrite/replace/demolish the old commit\nmessage\".  More like a chain (hopefully of length one, but I canot\nspll wuth a dam) of the messages, git log then showing the latest of \nthem, but allowing accessing earlier ones.\n\nOr another way to illustrate my idea: assume a create-once-no-delete\nfilesystem.\n\necho 42 > the_answr.txt\n\nOh, darn it...\n\nln -s the_answr.txt the_answer.txt\n\nNow both names still point to the content \"42\\n\".  The first SHA\nwould be over [\"42\\n\", \"the_answr.txt\"] and the second SHA over\n[\"42\\n\", \"the_answer.txt\"].\n\nBut I get the distinct feeling of beating a poor dead horse here,\nso I'll shut up.\n"},{"id":"267655","messageId":"20150808092432.GB24707@sigill.intra.peff.net","threadId":"40029","inReplyTo":"55C5364C.6040904@iki.fi","subject":"Re: wishlist: make it possible to amend commit messages after push to remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-08-08T09:24:32Z","receivedAt":"2015-08-08T09:24:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 07, 2015 at 06:50:52PM -0400, Jarkko Hietaniemi wrote:\n\n> Or another way to illustrate my idea: assume a create-once-no-delete\n> filesystem.\n> \n> echo 42 > the_answr.txt\n> \n> Oh, darn it...\n> \n> ln -s the_answr.txt the_answer.txt\n> \n> Now both names still point to the content \"42\\n\".  The first SHA\n> would be over [\"42\\n\", \"the_answr.txt\"] and the second SHA over\n> [\"42\\n\", \"the_answer.txt\"].\n\nBut you can't do that on a create-once filesystem; your symlink\noverwrites \"the_answr.txt\", which already exists. Obviously that is a\ntechnicality in the definition of \"create-once\", but if we take this as\nan analogy for a content-addressable object store, it is true. :) The\nname \"answr.txt\" in your case is really a sha1 \"1234abcd\", and we cannot\ncreate an object of that name that has anything _but_ the specific\nmatching content in it. Your options are then:\n\n  - add a level of indirection; when we look up 1234abcd, show some\n    other object instead (even though its content does not match\n    1234abcd). We have this already; it is the git-replace mechanism.\n\n  - during certain operations (e.g., showing the log), use 1234abcd as\n    an index into another data store. We have this, too: git-notes.\n\nI think I saw the objection elsewhere in the thread that these are not\nseamless to use. That is certainly true. Partially this is inherent\n(the client has to understand the extra object, and know when you want\nthat object versus the original). But git could also improve its\nhandling of these things.\n\nFor instance, we do not fetch notes from a remote by default. The big\nproblems is that the refs/remotes hierarchy is set really set up only to\nhold branches, so we do not know where to put them. There was a\ndiscussion around the v1.8.0 time-frame about improving this[1], but it\nwas never completed. That might be a productive direction if anyone is\nreally interested in this topic.\n\n-Peff\n\n[1] I didn't re-read the old thread, but glancing through, this looks\n    like a reasonable jumping-off point for reading:\n\n      http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165885\n"}]}