From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/76421 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: Gnus overrides.texi and WEBHACKDEVEL Date: Mon, 07 Feb 2011 04:20:39 +0900 Message-ID: <87wrldynp4.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83ei7makon.fsf@gnu.org> <838vxuaek9.fsf@gnu.org> <877hdebm01.fsf_-_@lifelogs.com> <831v3ma532.fsf@gnu.org> <8739o2bjci.fsf@lifelogs.com> <83wrle8p8q.fsf@gnu.org> <87lj1t1wuz.fsf@uwakimon.sk.tsukuba.ac.jp> <878vxt1b1i.fsf@uwakimon.sk.tsukuba.ac.jp> <83d3n5t6wp.fsf@gnu.org> <874o8h124y.fsf@uwakimon.sk.tsukuba.ac.jp> <838vxtt2t5.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1297020603 21810 80.91.229.12 (6 Feb 2011 19:30:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 6 Feb 2011 19:30:03 +0000 (UTC) Cc: tzz@lifelogs.com, ding@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 06 20:29:58 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PmAJ3-0001JY-Ir for ged-emacs-devel@m.gmane.org; Sun, 06 Feb 2011 20:29:57 +0100 Original-Received: from localhost ([127.0.0.1]:60525 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmAJ3-0007NO-1R for ged-emacs-devel@m.gmane.org; Sun, 06 Feb 2011 14:29:57 -0500 Original-Received: from [140.186.70.92] (port=54581 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmAIy-0007NJ-1K for emacs-devel@gnu.org; Sun, 06 Feb 2011 14:29:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmAIw-0007GM-Su for emacs-devel@gnu.org; Sun, 06 Feb 2011 14:29:51 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:46969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmAIv-0007G1-BI; Sun, 06 Feb 2011 14:29:49 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id E0C9397068F; Mon, 7 Feb 2011 04:29:46 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A84EA1A2C59; Mon, 7 Feb 2011 04:20:39 +0900 (JST) In-Reply-To: <838vxtt2t5.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.224 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:135655 gmane.emacs.gnus.general:76421 Archived-At: Eli Zaretskii writes: > If this is what you had in mind, then it's still manual work, and > thus prone to errors. I can do the same in a bound branch with > "bzr ci FILE1 FILE2 ...", thus "cherrypicking" only what should be > pushed. Not necessarily. For example, you may have pushable and non-pushable changes in the same file, in which case that doesn't allow you to select what to commit. Also, if the local changes would benefit from being preserved, you can commit them *immediately*, so the problem becomes more granular (and you can add hints to the commit message to indicate that some commits should not be cherry-picked). In some VCSes, there are tools that allow you to prohibit pulling certain revisions (eg, svnmerge.py), but I don't think bzr has such yet. > The original problem was that some people do not pay attention to what > "bzr status" says, and just do a "bzr ci", which pushes all the > modified files. I guess there's no way around vigilance. No, there isn't. However, committing all changes, using branch-per-feature in your workflow, and using appropriate commit messages for coherent changesets can reduce the amount of effort needed to implement vigilance. All of which are best practices, and don't involve that much extra effort once you're disciplined to them.