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

[Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx>]

On Fri, Nov 8, 2013 at 6:20 PM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>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..