all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Glenn Morris <rgm@gnu.org>, emacs-devel@gnu.org
Subject: Re: master cbef1e9 2/3: ; make change-history-commit
Date: Thu, 09 Apr 2015 13:26:44 -0700	[thread overview]
Message-ID: <5526E084.4060403@cs.ucla.edu> (raw)
In-Reply-To: <tgiod5nor6.fsf@fencepost.gnu.org>

On 04/09/2015 11:24 AM, Glenn Morris wrote:
> I had assumed that the ChangeLog would not be versioned at all now,
> but it seems like it is?

No, your assumption is correct.  For example, there is no ChangeLog here:

http://git.savannah.gnu.org/cgit/emacs.git/tree/ChangeLog

> I assumed that only the corrections would be versioned, and the full
> file would only appear in tarballs as a generated file.

Stefan indicated long ago that this was too drastic, and that we should 
keep ChangeLog history files in the repository, e.g., lisp/ChangeLog.10 
is still in the repository and hasn't changed since January 1's 
copyright-date edits.  ChangeLog.1 is another file like 
lisp/ChangeLog.10; i.e., it's another versioned ChangeLog history file 
that you can edit by hand whenever you like.

> I further assumed that the new-style generated log would always be
> separate from the old-style ChangeLog.1

Yes, that's correct.  The ChangeLog file in the tarball (built by 'make 
ChangeLog') is disjoint from ChangeLog.1, in that ChangeLog.1 contains 
only "older" entries and Changelog contains only "newer" entries.

> (I thought this was why the
> latter was renamed to ChangeLog.1), but it seems like you added new
> entries to ChangeLog.1?

Yes, the idea is that you can move the boundary line between "older" and 
"newer" by running "make change-history".  This automated procedure 
moves the boundary to be the present, and hence entries that until now 
would have been put into ChangeLog, are put into ChangeLog.1 and become 
part of the manually-edited history, which means that ChangeLog will 
become empty.  This is how you can fix old ChangeLog entries: run "make 
change-history", then edit ChangeLog.1 by hand and commit the result.

The advantage of this approach over the old Emacs approach, is that 
ordinary commits won't alter any ChangeLog files, which will make merge 
collisions less common.  (RMS's recent problem, for example, would have 
not occurred.)  And the advantage of this approach over the approach 
taken by Coreutils, Grep, etc. (which do not store ChangeLogs in the 
repository) is that it's easier to edit history by hand.  In effect, we 
have a hybrid approach, which uses Coreutils style for "recent" 
changelog entries and traditional Emacs style for "older" changelog entries.



  reply	other threads:[~2015-04-09 20:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20150409172246.20602.44549@vcs.savannah.gnu.org>
     [not found] ` <E1YgGAB-0005NP-Uc@vcs.savannah.gnu.org>
2015-04-09 18:24   ` master cbef1e9 2/3: ; make change-history-commit Glenn Morris
2015-04-09 20:26     ` Paul Eggert [this message]
2015-04-13  2:19       ` Glenn Morris
2015-04-13  6:58         ` Paul Eggert
2015-04-15 17:32           ` Glenn Morris
2015-04-15 17:39             ` Glenn Morris
2015-04-15 21:30               ` Paul Eggert
2015-04-09 22:35     ` Robin Templeton
2015-04-10  5:41       ` Paul Eggert
2015-04-11  4:33         ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5526E084.4060403@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=rgm@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.