From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: master cbef1e9 2/3: ; make change-history-commit Date: Thu, 09 Apr 2015 22:41:02 -0700 Organization: UCLA Computer Science Department Message-ID: <5527626E.7040307@cs.ucla.edu> References: <20150409172246.20602.44549@vcs.savannah.gnu.org> <87y4m1rkuq.fsf@panthera.terpri.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1428644490 23986 80.91.229.3 (10 Apr 2015 05:41:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Apr 2015 05:41:30 +0000 (UTC) To: Robin Templeton , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 10 07:41:22 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YgRgu-00061s-W2 for ged-emacs-devel@m.gmane.org; Fri, 10 Apr 2015 07:41:21 +0200 Original-Received: from localhost ([::1]:37559 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgRgu-0007lD-9z for ged-emacs-devel@m.gmane.org; Fri, 10 Apr 2015 01:41:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgRgk-0007l8-Db for emacs-devel@gnu.org; Fri, 10 Apr 2015 01:41:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgRgf-0005Ey-Dy for emacs-devel@gnu.org; Fri, 10 Apr 2015 01:41:10 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:53943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgRgf-0005Eq-8M for emacs-devel@gnu.org; Fri, 10 Apr 2015 01:41:05 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 8BF5FA60007; Thu, 9 Apr 2015 22:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auJ6U2BvGhDZ; Thu, 9 Apr 2015 22:41:02 -0700 (PDT) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id CA1D2A60003; Thu, 9 Apr 2015 22:41:02 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: <87y4m1rkuq.fsf@panthera.terpri.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185241 Archived-At: Robin Templeton wrote: > If only corrections to specific commits were stored, > it would be possible to amend the log messages as viewed with git > commands, perhaps using git object notes. I originally proposed that -- it's the approach Coreutils takes -- but the Coreutils approach turns out to be too much of a pain to understand and use in the context of Emacs development. Glenn did suggest object notes, but as I understand it Emacs VC doesn't support them. So I went with the best easy-enough approach that I could think of, an approach based on Emacs's tradition of ChangeLog history files. If we can think of something better, we should switch to it. > Separating corrections could also completely eliminate ChangeLog merge > conflicts. I don't see how. No matter how one versions corrections, merge conflicts can occur if concurrent developers generate different corrections for the same ChangeLog entry. Perhaps Git wouldn't identify them as conflicts, but they'd still be conflicts. Certainly object notes can have conflicts. That being said, I expect the current scheme will greatly reduce merge conflicts in practice. For example, I expect it would have avoided RMS's merge conflict that started that looooong recent thread.