* Can we all quietly agree to fix this commit log?
@ 2013-11-09 2:20 Bart Schaefer
2013-11-09 7:42 ` Wayne Davison
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Bart Schaefer @ 2013-11-09 2:20 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we all quietly agree to fix this commit log?
2013-11-09 2:20 Can we all quietly agree to fix this commit log? Bart Schaefer
@ 2013-11-09 7:42 ` Wayne Davison
2013-11-09 11:29 ` Aaron Schrab
2013-11-09 12:22 ` Mikael Magnusson
2 siblings, 0 replies; 6+ messages in thread
From: Wayne Davison @ 2013-11-09 7:42 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Zsh list
[-- 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..
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we all quietly agree to fix this commit log?
2013-11-09 2:20 Can we all quietly agree to fix this commit log? Bart Schaefer
2013-11-09 7:42 ` Wayne Davison
@ 2013-11-09 11:29 ` Aaron Schrab
2013-11-09 12:22 ` Mikael Magnusson
2 siblings, 0 replies; 6+ messages in thread
From: Aaron Schrab @ 2013-11-09 11:29 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we all quietly agree to fix this commit log?
2013-11-09 2:20 Can we all quietly agree to fix this commit log? Bart Schaefer
2013-11-09 7:42 ` Wayne Davison
2013-11-09 11:29 ` Aaron Schrab
@ 2013-11-09 12:22 ` Mikael Magnusson
2013-11-09 22:23 ` Bart Schaefer
2 siblings, 1 reply; 6+ messages in thread
From: Mikael Magnusson @ 2013-11-09 12:22 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh workers
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we all quietly agree to fix this commit log?
2013-11-09 12:22 ` Mikael Magnusson
@ 2013-11-09 22:23 ` Bart Schaefer
2013-11-09 22:52 ` Aaron Schrab
0 siblings, 1 reply; 6+ messages in thread
From: Bart Schaefer @ 2013-11-09 22:23 UTC (permalink / raw)
To: zsh workers
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we all quietly agree to fix this commit log?
2013-11-09 22:23 ` Bart Schaefer
@ 2013-11-09 22:52 ` Aaron Schrab
0 siblings, 0 replies; 6+ messages in thread
From: Aaron Schrab @ 2013-11-09 22:52 UTC (permalink / raw)
To: zsh workers
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-11-09 22:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-09 2:20 Can we all quietly agree to fix this commit log? Bart Schaefer
2013-11-09 7:42 ` Wayne Davison
2013-11-09 11:29 ` Aaron Schrab
2013-11-09 12:22 ` Mikael Magnusson
2013-11-09 22:23 ` Bart Schaefer
2013-11-09 22:52 ` Aaron Schrab
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).