Can we all quietly agree to fix this commit log?

Can we all quietly agree to fix this commit log?

[Bart Schaefer]

I know all the git doc says never to amend a commit after pushing because
it breaks clones, but I find this version number typo really bothersome.

Is there some procedure we can figure out that gets around that?

commit 375115c7dfd6dff576915d25fe2ecdd381dd9d81
Author: Peter Stephenson <p.w.stephenson@ntlworld.com>
Date:   Wed Nov 6 19:25:07 2013 +0000

    unposted: updates for 4.0.2-test-1.
    Update references to 4.0.2 to 4.0.3.
    Additional mod_export declarations.
    Additions to .distfiles.

Re: Can we all quietly agree to fix this commit log?

[Wayne Davison]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

On Fri, Nov 8, 2013 at 6:20 PM, Bart Schaefer <schaefer@brasslantern.com>wrote:

> I know all the git doc says never to amend a commit after pushing because
> it breaks clones, but I find this version number typo really bothersome.
>
> Is there some procedure we can figure out that gets around that?
>

If we just change the commit message for that commit in the remote repo,
then anyone doing a "git pull --rebase" will get their local repo
auto-fixed with nary a whimper.  Sadly, anyone that does a "git pull"
(which defaults to merging) will end up with a merge commit and a pretty
wacky version log (and I think it will continue to merge in all future
remote commits via new merges).  If someone ends up with such a merge
commit, they'd need to delete the merge (e.g. git reset --hard HEAD~1) and
switch to a --rebase pull to fix it up (or just re-clone).

Another issue is that the the zsh-5.0.2-test-1 tag points to
the 375115c7dfd6dff hash for the current commit, so any change to that
commit will generate a new hash, breaking the tag.  If the new hash is
forced into the remote repo's tag, anyone with the current tag in their
repo will not get the tag updated on a pull (without taking steps), and
will get an error if they ever attempt to "git push --tags".  Fortunately,
that's a pretty easy fix -- just delete the tag from the local repo and
pull the new one.

..wayne..

Re: Can we all quietly agree to fix this commit log?

[Aaron Schrab]

At 18:20 -0800 08 Nov 2013, Bart Schaefer <schaefer@brasslantern.com> wrote:
>I know all the git doc says never to amend a commit after pushing because
>it breaks clones, but I find this version number typo really bothersome.
>
>Is there some procedure we can figure out that gets around that?
>
>commit 375115c7dfd6dff576915d25fe2ecdd381dd9d81

An option that would clean it up somewhat, but without rewriting history 
would be to create a replacement ref for the mistaken commit.

  # Checking out tag should go into detached HEAD state
  git checkout zsh-5.0.2-test-1
  git commit --amend # Fixup the commit message
  git replace zsh-5.0.2-test-1 HEAD

At that point locally you'd see the amended commit message, unless you 
ask git to ignore replacement refs (e.g. `git --no-replace-objects 
log`).  But, replace refs are neither pushed nor fetched by default.  
Pushing can be done with:

  git push remote-name 'refs/replace/*:refs/replace/*'

And anybody who wanted to get the replacement ref 

  git fetch remote-name 'refs/replace/*:refs/replace/*'

People could also configure git to push and fetch those refs automatically 
whenever it's asked to interact with a given remote without being given 
a refspec.

  git config --add remote.remote-name.push  'refs/replace/*:refs/replace/*'
  git config --add remote.remote-name.fetch 'refs/replace/*:refs/replace/*'

But, the replacement ref would not affect any repository where it wasn't 
explicitly asked for in some way.  It's at least an easy first step.  If 
it's then determined that it isn't good enough, having created the 
replace ref doesn't really hurt anything; you'd still have the option of 
rewriting history.

Re: Can we all quietly agree to fix this commit log?

[Mikael Magnusson]

On 9 November 2013 03:20, Bart Schaefer <schaefer@brasslantern.com> wrote:
> I know all the git doc says never to amend a commit after pushing because
> it breaks clones, but I find this version number typo really bothersome.
>
> Is there some procedure we can figure out that gets around that?
>
> commit 375115c7dfd6dff576915d25fe2ecdd381dd9d81
> Author: Peter Stephenson <p.w.stephenson@ntlworld.com>
> Date:   Wed Nov 6 19:25:07 2013 +0000
>
>     unposted: updates for 4.0.2-test-1.
>     Update references to 4.0.2 to 4.0.3.
>     Additional mod_export declarations.
>     Additions to .distfiles.

I would highly recommend not doing this. If it really bothers you, you
can add a local note to the commit by
git notes add zsh-5.0.2-test-1
(this can also be pushed but notes don't get pulled by default anyway
(refs/notes/commits))

-- 
Mikael Magnusson

Re: Can we all quietly agree to fix this commit log?

[Bart Schaefer]

On Nov 9,  1:22pm, Mikael Magnusson wrote:
} Subject: Re: Can we all quietly agree to fix this commit log?
}
} On 9 November 2013 03:20, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > I know all the git doc says never to amend a commit after pushing because
} > it breaks clones, but I find this version number typo really bothersome.
} 
} I would highly recommend not doing this.

Given the tagging issue, I don't think Wayne's suggestion is quite what
I was hoping for.  Aaron's is a bit more like it.

If the "git replace" were pushed, would new clones see it, or would it
always be necessary to explicitly fetch the replacement refs?

Re: Can we all quietly agree to fix this commit log?

[Aaron Schrab]

At 14:23 -0800 09 Nov 2013, Bart Schaefer <schaefer@brasslantern.com> wrote:
>Given the tagging issue, I don't think Wayne's suggestion is quite what
>I was hoping for.  Aaron's is a bit more like it.
>
>If the "git replace" were pushed, would new clones see it, or would it
>always be necessary to explicitly fetch the replacement refs?

The replacement refs would always need to be fetched explicitly.  Doing 
a clone is basically just setting up a new local repository, adding a 
remote to it (including the default refspec that will be used for 
fetching), and then a fetch like any other fetch.  So the replacement 
refs wouldn't show up there either.

The only way to fix this type of issue without everybody who uses the 
repository needing to take some action would be to rewrite the history.