From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: esr@thyrsus.com (Eric S. Raymond) Newsgroups: gmane.emacs.devel Subject: The fixes-bug field Date: Thu, 16 Jan 2014 09:13:15 -0500 (EST) Message-ID: <20140116141315.CA3BE380835@snark.thyrsus.com> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1389881639 15856 80.91.229.3 (16 Jan 2014 14:13:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 14:13:59 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 16 15:14:02 2014 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 1W3nho-0000Cr-1r for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 15:14:00 +0100 Original-Received: from localhost ([::1]:32855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3nhn-0006us-CX for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 09:13:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3nhf-0006tg-AC for emacs-devel@gnu.org; Thu, 16 Jan 2014 09:13:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3nha-0005N5-L1 for emacs-devel@gnu.org; Thu, 16 Jan 2014 09:13:51 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:59786 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3nha-0005Mz-D6 for emacs-devel@gnu.org; Thu, 16 Jan 2014 09:13:46 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id CA3BE380835; Thu, 16 Jan 2014 09:13:15 -0500 (EST) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 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:168529 Archived-At: Eli Zaretskii asked: > Which reminds me: what about the "fixes bug" field of the commit > metadata? are they copied into the git repo? If so, how can I display > them in git? The "fixes bug" field in the Bazaar logs is not copied in to the git logs. This is because it's not actually part of the Bazaar log text. It is, one member (often the only member) of a per-revision property/value list. The Bazaar fast-export plugin can write these property lists in a extension of fast-import format, but normally does not because Git cannot interpret that extension. Thus, these properties are normally lost in translation to git. reposurgeon, on the other hand, *can* read and process these properties (they're the one Bazaar feature I really like, and I wish git supported them). In theory I could salvage these properties and append a report of them them to the end of the log messages on their corresponding git commits. There's a complication, though. Quoting from the reposurgeon manual: Limitation: bzr suffers from deep confusion over whether its unit of work is a repository or a floating branch that might have been cloned from a repo or created from scratch, and might or might not be destined to be merged to a repo one day. Its exporter only works on branches, but its importer creates repos. Thus, a rebuild operation will produce a subdirectory structure that differs from what you expect. Look for your content under the subdirectory 'trunk'. This reflects the state of play when I wrote the Bazaar support fore reposurgeon in early 2011. I know how to get a fast-import-compatible dump of a branch with the Bazaar properties in place, but I don't know how to get a fast-import dump of an *entire Bazaar repo*, with or without the properties. Unless the Bazaar exporter has been up-gunned while I wasn't looking, this might literally require iterating across a branch list and stitching dumps together by hand. While I could do this with reposurgeon, the operation would be an error-prone pain in the ass. Because of this, I had been planning to do the full-bore git conversion based on the existing git mirror, rather than the Bazaar repo. To save these properties I'd have to reverse that decision. The additional complications could easily cost me another week of work wrestling the Bazaar exporter into submission. TL;DR: Possible, but a serious PITA. If this is just an It Would Be Nice rather than being key to an established workflow I'd rather not go there. -- Eric S. Raymond The IRS has become morally corrupted by the enormous power which we in Congress have unwisely entrusted to it. Too often it acts like a Gestapo preying upon defenseless citizens. -- Senator Edward V. Long