From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Bzr taskbranches and ChangeLog Date: Sat, 21 Dec 2013 10:03:56 +0200 Message-ID: <83vbyiaavn.fsf@gnu.org> References: <8761qjfdqt.fsf@thinkpad.tsdh.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1387613059 24631 80.91.229.3 (21 Dec 2013 08:04:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Dec 2013 08:04:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 21 09:04:25 2013 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 1VuHXs-0004Ff-Ur for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2013 09:04:25 +0100 Original-Received: from localhost ([::1]:53322 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuHXs-0007Df-Hs for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2013 03:04:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuHXl-00074p-1z for emacs-devel@gnu.org; Sat, 21 Dec 2013 03:04:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuHXf-0000N2-N1 for emacs-devel@gnu.org; Sat, 21 Dec 2013 03:04:16 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:54729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuHXf-0000M0-FT; Sat, 21 Dec 2013 03:04:11 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MY500L00C08XB00@a-mtaout22.012.net.il>; Sat, 21 Dec 2013 10:04:09 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MY500LJQD2XXE60@a-mtaout22.012.net.il>; Sat, 21 Dec 2013 10:04:09 +0200 (IST) In-reply-to: <8761qjfdqt.fsf@thinkpad.tsdh.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:166688 Archived-At: > From: Tassilo Horn > Date: Fri, 20 Dec 2013 21:50:50 +0100 > > while reading http://www.emacswiki.org/emacs/BzrForEmacsDevs I don't get > exactly how to deal with ChangeLog entries when working with > taskbranches. As Xue pointed out, a large part of the solution is the changelog_merge plugin. With some bzr distributions, it comes bundled. It will do its job silently without you having to do anything at all. However, you need to remember one thing: changelog_merge puts the merged entries above (i.e., before) your local ones. So you will need to move them forward before committing to Savannah, because our commit policy is to have the ChangeLog entries in the (reverse) order of commits. > For example, I've just created a local branch bug-16090 which fixes that > bug. It's complete, but I want to wait with pushing until Stefan had a > look, so I'll surely need to merge from trunk some times. > > With git I would commit my changes (no ChangeLog entries right now) > locally, then keep rebasing onto master until Stefan gives his go, then > write the ChangeLog entry, commit that too, squash that commit with the > code change commit, and then push one single commit with the code and > ChangeLog changes. > > How do I do something similar with bzr? When I work on a feature branch, I usually don't write ChangeLog entries, only the commit messages. Then I merge to the trunk (a bound branch), test the changes there, write the ChangeLog entries there, and commit upstream. If someone commits between my merge to the trunk and commit to Savannah (whcih will require me to "bzr update" before committing upstream), and those commits touch the ChangeLog files where I added my entries, I move my ChangeLog entries to the top of the file before committing. > When I get the emacswiki page right, I should write my ChangeLog entry > to some temporary file, and then commit locally providing the entries > (without author/date line) as commit message. Then I keep on merging > from an updated trunk until Stefan gives his go, and then I use the > commit message from the log to create a real ChangeLog entry. Finally, > I commit that and push. > > Correct? But doesn't that lead to a log like > > - ChangeLog commit > - Merge commit > - [...] > - Merge commit > - Original code commit > > > e.g., the eventual ChangeLog commit might be far off the original code > commit it is documenting? First, while waiting for approval, you only need to merge from trunk if the changes there touch the files you modified, or if a lot of structural changes were made (like files deleted or renamed). Otherwise, no need to merge from trunk, just leave your branch alone until you get the approval to push. Bzr (like git and hg) is very good at merging, so no need for the "merge fever". And second, with the workflow I described above, the problems with ChangeLog are never a concern. Commit messages are good enough to keep the information about your work, if you need that later. In general, I find that I can write ChangeLog entries before the final commit upstream just by looking at the output of "bzr diff", and don't need to consult my commit messages, except in very rare cases. In fact, you can just walk the "bzr diff" hunks one by one in an Emacs buffer, and invoke "C-x 4 a" from there: Diff Mode usually does TRT with that.