Absentee log entry and Git question

Absentee log entry and Git question

[Po Lu]

There is no log message for:

commit fa24bbb631fce7c5110dc322264224842cbb28d8
Author: Alan Third <alan@idiocy.org>
Date:   Sun Jul 23 12:00:30 2023 +0100

    Simplify the EmacsLayer double buffering code (bug#63187)

I suggest:

* src/nsfns.m (ns_set_inhibit_double_buffering): New function.
(ns_frame_parm_handlers): Register new handler for
`inhibit-double-buffering'
(Fx_create_frame) [NS_IMPL_COCOA]: Apply default value of
Qinhibit_double_buffering on Mac OS 10.14 and later.

Yet after running `git filter-branch' to amend the log message, the
server refuses to accept the updated state of the repository, which, I
suppose, is down to my privileges being insufficient to run
administrator commands.  Would one of the project administrators care to
do the honors?

I dimly recall asking a similar question in the past, so please excuse
me if I'm repeating myself.  Thanks.

Re: Absentee log entry and Git question

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> There is no log message for:
>
> commit fa24bbb631fce7c5110dc322264224842cbb28d8
> Author: Alan Third <alan@idiocy.org>
> Date:   Sun Jul 23 12:00:30 2023 +0100
>
>     Simplify the EmacsLayer double buffering code (bug#63187)
>
> I suggest:
>
> * src/nsfns.m (ns_set_inhibit_double_buffering): New function.
> (ns_frame_parm_handlers): Register new handler for
> `inhibit-double-buffering'
> (Fx_create_frame) [NS_IMPL_COCOA]: Apply default value of
> Qinhibit_double_buffering on Mac OS 10.14 and later.
>
> Yet after running `git filter-branch' to amend the log message, the
> server refuses to accept the updated state of the repository, which, I
> suppose, is down to my privileges being insufficient to run
> administrator commands.  Would one of the project administrators care to
> do the honors?
>
> I dimly recall asking a similar question in the past, so please excuse
> me if I'm repeating myself.  Thanks.

Quote from git filter-branch's man page

  WARNING! The rewritten history will have different object names for all
  the objects and will not converge with the original branch. You will not
  be able to easily push and distribute the rewritten branch on top of the
  original branch.

Re: Absentee log entry and Git question

[Po Lu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Quote from git filter-branch's man page
>
>   WARNING! The rewritten history will have different object names for all
>   the objects and will not converge with the original branch. You will not
>   be able to easily push and distribute the rewritten branch on top of the
>   original branch.

I see.  Is it possible to modify a revision's properties without
incurring such divergence?

Re: Absentee log entry and Git question

[Andreas Schwab]

On Mai 09 2024, Po Lu wrote:

> I see.  Is it possible to modify a revision's properties without
> incurring such divergence?

No.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Absentee log entry and Git question

[Po Lu]

Andreas Schwab <schwab@linux-m68k.org> writes:

> No.

Alright, so how should this error be corrected in the VC log and
generated ChangeLog files?  It would be dreadfully simple to forget when
that time eventually comes.

Re: Absentee log entry and Git question

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>  emacs-devel@gnu.org
> Date: Thu, 09 May 2024 16:22:32 +0800
> 
> Andreas Schwab <schwab@linux-m68k.org> writes:
> 
> > No.
> 
> Alright, so how should this error be corrected in the VC log and
> generated ChangeLog files?  It would be dreadfully simple to forget when
> that time eventually comes.

The VC log is carved in stone with Git, so it cannot be corrected.

We _can_ correct that in the generated ChangeLog file, though.  To
this end, one needs to generate ChangeLog.4, then edit it, and then
commit the fixed version.  This can be done now, or it can be deferred
until the first pretest tarball is made for the next version.

Re: Absentee log entry and Git question

[Arsen Arsenović]

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

Hi.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>>  emacs-devel@gnu.org
>> Date: Thu, 09 May 2024 16:22:32 +0800
>> 
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>> 
>> > No.
>> 
>> Alright, so how should this error be corrected in the VC log and
>> generated ChangeLog files?  It would be dreadfully simple to forget when
>> that time eventually comes.
>
> The VC log is carved in stone with Git, so it cannot be corrected.
>
> We _can_ correct that in the generated ChangeLog file, though.  To
> this end, one needs to generate ChangeLog.4, then edit it, and then
> commit the fixed version.  This can be done now, or it can be deferred
> until the first pretest tarball is made for the next version.

Could an empty commit with just the missing ChangeLog hunk work? It can
be created using:

  git commit --allow-empty

BTW, it might make sense to reuse/reimplement some of the git
infrastructure GCC uses to prevent pushes without matching ChangeLogs.

Have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: Absentee log entry and Git question

[Eli Zaretskii]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: Po Lu <luangruo@yahoo.com>,  schwab@linux-m68k.org,
>  gerd.moellmann@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 09 May 2024 11:48:00 +0200
> 
> > The VC log is carved in stone with Git, so it cannot be corrected.
> >
> > We _can_ correct that in the generated ChangeLog file, though.  To
> > this end, one needs to generate ChangeLog.4, then edit it, and then
> > commit the fixed version.  This can be done now, or it can be deferred
> > until the first pretest tarball is made for the next version.
> 
> Could an empty commit with just the missing ChangeLog hunk work? It can
> be created using:
> 
>   git commit --allow-empty

It won't help, so no.

> BTW, it might make sense to reuse/reimplement some of the git
> infrastructure GCC uses to prevent pushes without matching ChangeLogs.

We already have such hooks, but that commit was more than 6 months
ago.

Re: Absentee log entry and Git question

[Sean Allred]

Po Lu <luangruo@yahoo.com> writes:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>> No.
> Alright, so how should this error be corrected in the VC log and
> generated ChangeLog files?

I tend to think this would be an over-engineered solution unless this
happens often, but if you're sufficiently-motivated, you could look at
using notes refs for this purpose.[1] git-notes are intended (for the
most part) to add information to existing history, so a system could
certainly be constructed during changelog gen that would read from a
note as well if it exists (or perhaps in an overriding fashion).

If you do go down this route, please CC me; I'd be interested to see
where you end up.

[1]: https://git-scm.com/docs/git-notes

--
Sean Allred

Re: Absentee log entry and Git question

[tomas]

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

On Thu, May 09, 2024 at 09:48:53AM +0200, Gerd Möllmann wrote:
> Po Lu <luangruo@yahoo.com> writes:

[...]

> > Yet after running `git filter-branch' to amend the log message, the
> > server refuses to accept the updated state of the repository, which, I
> > suppose, is down to my privileges being insufficient to run
> > administrator commands.  Would one of the project administrators care to
> > do the honors?
> >
> > I dimly recall asking a similar question in the past, so please excuse
> > me if I'm repeating myself.  Thanks.
> 
> Quote from git filter-branch's man page
> 
>   WARNING! The rewritten history will have different object names for all
>   the objects and will not converge with the original branch. You will not
>   be able to easily push and distribute the rewritten branch on top of the
>   original branch.

To restate in more detail -- you would have to at least add the -f (--force)
flag to your push. That said, the remote repo might be set up to refuse this
operation (a sensible thing to do for a public repo, see below).

BEWARE: this will break everyone else's "git fetch" aka "git pull" if they
have a clone of the repo, because the histories don't match. They would
(more or less) have to throw away their local clones and re-clone. With
whatever gymnastics it takes to rescue their local changes.

So whether you actually want to do this will depend on how many clones
of that (part of) the repo you think are out there and whether you think
you can talk to the people having one of those.

Changing history is hard. Especially if more than one has looked at
it :-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]