Re: master 511bd2b8bc3: Make emerge-m-t-f obsolete in favor of make-temp-file

Re: master 511bd2b8bc3: Make emerge-m-t-f obsolete in favor of make-temp-file

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> branch: master
> commit 511bd2b8bc32b2867bd8d63311d827a821e6ef47
> Author: Stefan Kangas <stefankangas@gmail.com>
> Commit: Stefan Kangas <stefankangas@gmail.com>
>
>     Make emerge-m-t-f obsolete in favor of make-temp-file
>     
>     * lisp/vc/emerge.el (emerge-make-temp-file): Make obsolete in favor of
>     'make-temp-file'.  Update all callers.

Btw, folks, this is an exemplar of the kind of commit that doesn't
warrant a commit title: the log entry itself is perfectly adequate.

Since Git doesn't provide for empty commit titles, is there some
convention we can adopt to guarantee that the redundant title isn't
reproduced within generated ChangeLog files?  If you compare
ChangeLog.android now to its contents when it was first checked in,
you'll quickly understand my point.

Re: master 511bd2b8bc3: Make emerge-m-t-f obsolete in favor of make-temp-file

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> > branch: master
> > commit 511bd2b8bc32b2867bd8d63311d827a821e6ef47
> > Author: Stefan Kangas <stefankangas@gmail.com>
> > Commit: Stefan Kangas <stefankangas@gmail.com>
> >
> >     Make emerge-m-t-f obsolete in favor of make-temp-file
> >
> >     * lisp/vc/emerge.el (emerge-make-temp-file): Make obsolete in favor of
> >     'make-temp-file'.  Update all callers.
>
> Btw, folks, this is an exemplar of the kind of commit that doesn't
> warrant a commit title: the log entry itself is perfectly adequate.

That advice is fine for one line entries.  If the log entry is two
lines, it will be hard to read in displays that only show the first
line.

> Since Git doesn't provide for empty commit titles, is there some
> convention we can adopt to guarantee that the redundant title isn't
> reproduced within generated ChangeLog files?  If you compare
> ChangeLog.android now to its contents when it was first checked in,
> you'll quickly understand my point.

I don't understand what you're asking, sorry.  What is the problem you
see in ChangeLog.android?

Re: master 511bd2b8bc3: Make emerge-m-t-f obsolete in favor of make-temp-file

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Since Git doesn't provide for empty commit titles, is there some
>> convention we can adopt to guarantee that the redundant title isn't
>> reproduced within generated ChangeLog files?  If you compare
>> ChangeLog.android now to its contents when it was first checked in,
>> you'll quickly understand my point.
>
> I don't understand what you're asking, sorry.  What is the problem you
> see in ChangeLog.android?

It's not what I see now, but rather what I saw.  On 4 August, it was
replete with badly formatted entries, but more pointedly entries with
completely redundant and meaningless commit titles, which I was forced
to manually remove.

Re: master 511bd2b8bc3: Make emerge-m-t-f obsolete in favor of make-temp-file

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> > I don't understand what you're asking, sorry.  What is the problem you
> > see in ChangeLog.android?
>
> It's not what I see now, but rather what I saw.  On 4 August, it was
> replete with badly formatted entries, but more pointedly entries with
> completely redundant and meaningless commit titles, which I was forced
> to manually remove.

I see, yes, that doesn't look very nice.  That should normally be
taken care of automatically by the scripts that generate the
ChangeLog.N file for us.  This is ideally done only once, before
releasing a tarball (for a pretest or a release).

Is there a need for a separate ChangeLog.android file though?  We
don't keep such files around for other ports.  Isn't there a risk that
we will have duplicate entries in the standard ChangeLog?

Re: master 511bd2b8bc3: Make emerge-m-t-f obsolete in favor of make-temp-file

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Is there a need for a separate ChangeLog.android file though?  We
> don't keep such files around for other ports.  Isn't there a risk that
> we will have duplicate entries in the standard ChangeLog?

AFAIK, feature branch commits don't appear in release ChangeLog files,
only a single enormous entry for the commit which merges the feature
branch.