Zsh Mailing List Archive
Messages sorted by:
Re: Can we all quietly agree to fix this commit log?
- X-seq: zsh-workers 31942
- From: Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: Can we all quietly agree to fix this commit log?
- Date: Fri, 8 Nov 2013 23:42:11 -0800
- Cc: Zsh list <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=UI8Pgr4qVldMiUeDYleTPu7Z9GLvXYUnAi605pWMAgU=; b=wb4S1Zsl0YG+L58XOnobMkEXHf+s+zze4LAu6Y3CCoEVoYugvBVi/u5auERPsTHTnl x2XvZ6uBkzojfjKwRcnxMk3eA54pJUURv2b5yBS3GdwMl0xqMoeMvqaRRkvsvbZJetZj CPq0OpIRX4yc9b8FYKAZURGRc1ZskThE0CZ3dMFjNHEYbfMpzZ7X0KAk/rjmGYFkRh1b I3jgu0JHXH4prDVJ1YdZjYMqHN62HwWS/a2YMbrDm4lm4MOUHYShXuiwqWlRtrtHGdwY enXqAXX8jA5UyALbpwt75U87r/Ir0qXBIc18LpB/jhMVqE7CmGhMUFIFvn05sBMx7jNU ON/A==
- In-reply-to: <131108182028.ZM26321@torch.brasslantern.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <131108182028.ZM26321@torch.brasslantern.com>
- Sender: 4wayned@xxxxxxxxx
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.
Messages sorted by: