This is the mail archive of the
mailing list for the GCC project.
Re: Fixing gcc git logs
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Jerry <jvdelisle at charter dot net>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 2 Jan 2020 22:03:05 +0000
- Subject: Re: Fixing gcc git logs
- References: <firstname.lastname@example.org>
On Thu, 2 Jan 2020 at 02:00, Jerry <email@example.com> wrote:
> In the following git log entry, I made a typo on the PR number in the
> libgfortran ChangeLog file. I noticed this right after the git commit,
> while editing the git log.
> So I quit the edit without saving and git reported that the commit was
> Then I edited the my local ChangeLog file, did git add . and git commit
> again. In this case the git log edit started as usual and I recopied
> the correct text into my editor (VI) and saved it. The commit proceeded
> as I expected. Then I did the git svn dcommit
N.B. before doing the 'git svn dcommit' you can always do 'git show'
to see the most recent commit, to double-check it looks fine before
doing the svn dcommit. That's your last chance to fix something.
> Well the git log ended up like this. How to fix? How to avoid?
I'm not sure what you're asking. How to avoid what?
It looks like you just didn't paste the correct text into the editor.
Git isn't going to revert to an older version of the git log text,
which was never actually used. Maybe your clipboard had the old (bad)
text still, and that's what you pasted. This looks like user error,
not a Git problem.
> The 90274 should have been 90374. The actual committed files are OK.
> commit 86e1d9f75bae096922664755d037f2a9d85e2a24 (HEAD -> trunk,
> svn/trunk, origin/trunk, origin/master)
This means the commit is already on svn/trunk, so you can't fix it
now. That would alter the history of trunk, which we don't allow.
> Author: jvdelisle <jvdelisle@138bc75d-0d04-0410-961f-82ee72b054a4>
> Date: Thu Jan 2 00:57:31 2020 +0000
> PR 90374 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d edit descriptors.
The good news is that the summary line above has the right number,
which is probably what matters most in Git-land, as the summaries will
be viewed often.