emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git history tracking across renames (and emacs support)


From: Eli Zaretskii
Subject: Re: git history tracking across renames (and emacs support)
Date: Sat, 14 Jul 2018 10:05:36 +0300

> From: Jonas Bernoulli <address@hidden>
> Date: Fri, 13 Jul 2018 15:13:41 -0500
> Cc: Clément Pit-Claudel <address@hidden>,
>       Richard Stallman <address@hidden>, Emacs developers <address@hidden>
> 
> The functionality should be split like so:
> 
> 1. Generate a list of all changed symbols.
> 2. Format the list according to some preference.
> 3. Insert the formatted list somewhere.

Sounds reasonable, thanks.

> Whether *Emacs* should ChangeLog files is a different discussion
> (which I don't want to take part in)

This has never been part of this discussion, because that ship has
sailed more than 3 years ago, and I don't think it's coming back.

> some projects (currently including Emacs) use ChangeLog files,
> while other (possibly including Emacs in the future) put the list of
> modified symbols into the commit message only.  And regardless of where
> the information is put, not every project uses the same format.

Actually, Emacs stopped maintaining ChangeLog files in Apr 2015.  We
nowadays generate ChangeLog from the Git log as part of preparing a
release tarball.  The ChangeLog-like entries we've been discussing are
those we put into the Git commit log messages.

> >From a non-technical perspective the hard part is agreeing on what the
> one and only correct way of recording this information is, which I think
> we never be able to agree on.  We (everyone using version control) also
> don't have to.  So lets keep those things separate.

They are not entirely separate, though: my impression is that some of
the friction uncovered in this and similar discussions is that people
have difficulties integrating the technical part (i.e. generation of
the log entries) into their workflows.  So one way of making the
friction lower is to make this integration easier by providing
convenience features that cater to more workflows than we currently
support.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]