From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Bzr taskbranches and ChangeLog Date: Sat, 21 Dec 2013 09:44:41 +0100 Message-ID: <87d2kqtwxy.fsf@thinkpad.tsdh.org> References: <8761qjfdqt.fsf@thinkpad.tsdh.org> <83vbyiaavn.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387615498 13588 80.91.229.3 (21 Dec 2013 08:44:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Dec 2013 08:44:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 21 09:45:04 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 1VuIBE-0005zQ-EK for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2013 09:45:04 +0100 Original-Received: from localhost ([::1]:53464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuIBE-0000rD-0j for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2013 03:45:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuIB5-0000hg-HW for emacs-devel@gnu.org; Sat, 21 Dec 2013 03:45:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuIB0-0002kI-8n for emacs-devel@gnu.org; Sat, 21 Dec 2013 03:44:55 -0500 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:46946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuIAu-0002jg-IP; Sat, 21 Dec 2013 03:44:44 -0500 Original-Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 533C120E68; Sat, 21 Dec 2013 03:44:43 -0500 (EST) Original-Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sat, 21 Dec 2013 03:44:44 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:to:cc:subject:references:date :in-reply-to:message-id:mime-version:content-type; s=smtpout; bh=ONVTNoihcAE3X1YzuqU/f4IXEbs=; b=c4u5uIDVSax4hAnrSwaRHNieWNGG mvFf9muQ+hYbNuy4K19tkkc32Jq89YtXkXCadlPm71igOz3AiEzOQVwB5/EBDFqv mET/7uUdtipc+zYIfzyyPcm/GPs1YzV5d89hLd9Cb6H0Ftu1sYiYoYCigOX6/YED qYw2KsEyknJGvhM= X-Sasl-enc: LIU7Rc0n46gQsKCFKzxZiGDmh5xSO9Wz88kqUWQi7C2/ 1387615483 Original-Received: from thinkpad.tsdh.org (unknown [91.67.164.26]) by mail.messagingengine.com (Postfix) with ESMTPA id CB3036800CB; Sat, 21 Dec 2013 03:44:42 -0500 (EST) Mail-Followup-To: Eli Zaretskii , emacs-devel@gnu.org In-Reply-To: <83vbyiaavn.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 21 Dec 2013 10:03:56 +0200") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 66.111.4.27 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:166694 Archived-At: Eli Zaretskii writes: > 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. Ah ok, then it does work as it's supposed. I've read the "emit OTHERS first" in its docs as if my changes were kept on top. >> 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. Ok, I see. > 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". Ok, even better. > 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. Yes, that's what I've usually done, too. Thanks, Tassilo