From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: The ChangeLog and merge conflicts Date: Tue, 10 Feb 2015 06:55:12 +0000 Message-ID: References: <871tlytyut.fsf@fencepost.gnu.org> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1134ea0650b5cd050eb65e0c X-Trace: ger.gmane.org 1423551330 30962 80.91.229.3 (10 Feb 2015 06:55:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Feb 2015 06:55:30 +0000 (UTC) Cc: emacs-devel To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 10 07:55:29 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 1YL4jJ-0002fc-2D for ged-emacs-devel@m.gmane.org; Tue, 10 Feb 2015 07:55:29 +0100 Original-Received: from localhost ([::1]:37930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YL4jI-0004XJ-JJ for ged-emacs-devel@m.gmane.org; Tue, 10 Feb 2015 01:55:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YL4jA-0004PT-Sc for emacs-devel@gnu.org; Tue, 10 Feb 2015 01:55:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YL4j5-0000vt-BP for emacs-devel@gnu.org; Tue, 10 Feb 2015 01:55:19 -0500 Original-Received: from mail-ob0-x230.google.com ([2607:f8b0:4003:c01::230]:54609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YL4j3-0000v1-Lf; Tue, 10 Feb 2015 01:55:13 -0500 Original-Received: by mail-ob0-f176.google.com with SMTP id wo20so30274247obc.7; Mon, 09 Feb 2015 22:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uWH1AZFb91ebUhnx6kUq/U3yT/zGVzrm/2vLMJsph7A=; b=BKuLyTrP1BZUVGEEMWnE7bHF9Lhtkk5+SDWM7z9l8c0jZTOVBi3g52KH5z9tEgql21 /METcPrd0DQ/TXtBe+iBRb4h4I4ZWxMDp6xkpty350+sqjDAVcbfUuzanWR1EMT8/6i2 E6D8JVQSSswtoDiT8gp36VOxBALzYPJ/iPJMEUn6UtJpIK5GTHrZzv/w3uOPj8G5vpfq 7WIqPJHQyHqo24xzIV7T+r+tp7pVimZlD7OLJlFN5jT4139cQPvj7UQw7HDadIYfq+Ay Q/4CUUceUTZgsCRqHTejOqB694dTnLh7SmT7wqKBMqDfUB1A7iPPARGCVe0kjGBLSozZ je4g== X-Received: by 10.202.203.78 with SMTP id b75mr9544429oig.27.1423551312735; Mon, 09 Feb 2015 22:55:12 -0800 (PST) Original-Received: by 10.76.125.1 with HTTP; Mon, 9 Feb 2015 22:55:12 -0800 (PST) Original-Received: by 10.76.125.1 with HTTP; Mon, 9 Feb 2015 22:55:12 -0800 (PST) In-Reply-To: <871tlytyut.fsf@fencepost.gnu.org> X-Google-Sender-Auth: LKhCYdfbWUb9kGGe9P1g1Iag1nQ X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::230 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:182783 Archived-At: --001a1134ea0650b5cd050eb65e0c Content-Type: text/plain; charset=UTF-8 Thanks! I'll check it out! On 10 Feb 2015 00:05, "David Kastrup" wrote: > Artur Malabarba writes: > > > For this short period of time that I've been trying to help here, there > is > > one workflow issue that's really been bugging me: the ChangeLog file > causes > > conflicts on every merge. > > > > This pops up in two situations: > > > > 1. I do some work on another branch for a couple of days, while adding a > > ChangeLog entry with each commit. I proceed to merge with master. > > > > 2. Someone submits a patch and is kind enough to include a ChangeLog > entry > > in it. As usual, the patch is only applied after (in the very least) a > few > > days. > > > > If anything at all has happened between branch/patch creation and the > > merge, a conflict is guaranteed to happen. > > Of course, the reason for this is that every new entry goes at the top of > > the ChangeLog, and every commit is accompanied with an entry. > > > > I'm just wondering whether there's a solution around this that I'm not > > aware of. Is there something I should do differently? > > > > These conflicts aren't complicated at all to solve, but it gets > irritating > > to have to fix them every single time. > > Take a look for the git-merge-changelog program (the respective Debian > package is called just that). > > It's still sort of a nuisance to maintain the corresponding entry in the > top level .gitattributes file (since it is itself under version > control), but at least this works reasonably well for the non-toplevel > ChangeLog file merges. > > -- > David Kastrup > --001a1134ea0650b5cd050eb65e0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks! I'll check it out!

On 10 Feb 2015 00:05, "David Kastrup" = <dak@gnu.org> wrote:
Artur Malabarba <bruce.connor.am@gmail.com> writes:
> For this short period of time that I've been trying to help here, = there is
> one workflow issue that's really been bugging me: the ChangeLog fi= le causes
> conflicts on every merge.
>
> This pops up in two situations:
>
> 1. I do some work on another branch for a couple of days, while adding= a
> ChangeLog entry with each commit. I proceed to merge with master.
>
> 2. Someone submits a patch and is kind enough to include a ChangeLog e= ntry
> in it. As usual, the patch is only applied after (in the very least) a= few
> days.
>
> If anything at all has happened between branch/patch creation and the<= br> > merge, a conflict is guaranteed to happen.
> Of course, the reason for this is that every new entry goes at the top= of
> the ChangeLog, and every commit is accompanied with an entry.
>
> I'm just wondering whether there's a solution around this that= I'm not
> aware of. Is there something I should do differently?
>
> These conflicts aren't complicated at all to solve, but it gets ir= ritating
> to have to fix them every single time.

Take a look for the git-merge-changelog program (the respective Debian
package is called just that).

It's still sort of a nuisance to maintain the corresponding entry in th= e
top level .gitattributes file (since it is itself under version
control), but at least this works reasonably well for the non-toplevel
ChangeLog file merges.

--
David Kastrup
--001a1134ea0650b5cd050eb65e0c--