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

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

[Jarkko Hietaniemi]

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?

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

[Kevin Daudt]

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

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

[Junio C Hamano]

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

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

[Jarkko Hietaniemi]

On Friday-201508-07 12:59, Junio C Hamano wrote:
> 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.
> ...
> If you really "get" it, you wouldn't be complaining about the
> "impossibility" part;-)

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

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

[Jarkko Hietaniemi]

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.

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

[Johannes Schindelin]

Hi,

On 2015-08-07 19:10, Jarkko Hietaniemi wrote:

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

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

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

[Philip Oakley]

From: "Jarkko Hietaniemi" <jhi@iki.fi>
> 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.

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 

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

[Jarkko Hietaniemi]

On Friday-201508-07 15:38, Johannes Schindelin wrote:
> 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.

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.

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

[Jeff King]

On Fri, Aug 07, 2015 at 06:50:52PM -0400, Jarkko Hietaniemi wrote:

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