From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: log format for vc-bzr Date: Tue, 08 Dec 2009 23:36:53 +0100 Message-ID: <877hsxrt2y.fsf@telefonica.net> References: <200912081747.nB8HlwPR021836@godzilla.ics.uci.edu> <874oo1w9y1.fsf@telefonica.net> <87tyw1uss6.fsf@telefonica.net> <200912082203.nB8M3FLP023771@godzilla.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1260318220 7989 80.91.229.12 (9 Dec 2009 00:23:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Dec 2009 00:23:40 +0000 (UTC) Cc: =?utf-8?Q?=C3=93scar?= Fuentes , Andreas Schwab , emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 09 01:23:33 2009 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.50) id 1NIAL5-0008Fv-3I for ged-emacs-devel@m.gmane.org; Wed, 09 Dec 2009 01:23:31 +0100 Original-Received: from localhost ([127.0.0.1]:46420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIAL4-0006z0-Pr for ged-emacs-devel@m.gmane.org; Tue, 08 Dec 2009 19:23:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NI8gP-0000Lo-D7 for emacs-devel@gnu.org; Tue, 08 Dec 2009 17:37:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NI8gK-00008d-Hl for emacs-devel@gnu.org; Tue, 08 Dec 2009 17:37:24 -0500 Original-Received: from [199.232.76.173] (port=57811 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NI8gK-00008E-BL for emacs-devel@gnu.org; Tue, 08 Dec 2009 17:37:20 -0500 Original-Received: from impaqm5.telefonica.net ([213.4.138.5]:55466) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NI8gJ-0002PN-Pk for emacs-devel@gnu.org; Tue, 08 Dec 2009 17:37:20 -0500 Original-Received: from IMPmailhost6.adm.correo ([10.20.102.127]) by IMPaqm5.telefonica.net with bizsmtp id Em2j1d0222kvMAa3Rmcvw8; Tue, 08 Dec 2009 23:36:55 +0100 Original-Received: from qcore ([83.34.21.64]) by IMPmailhost6.adm.correo with BIZ IMP id Emcu1d00E1NxSM71mmcul9; Tue, 08 Dec 2009 23:36:55 +0100 X-TE-authinfo: authemail="981711563$telefonica.net" |auth_email="981711563@telefonica.net" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitnetc01" In-Reply-To: <200912082203.nB8M3FLP023771@godzilla.ics.uci.edu> (Dan Nicolaescu's message of "Tue, 8 Dec 2009 14:03:15 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Tue, 08 Dec 2009 19:22:01 -0500 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:118408 Archived-At: Dan Nicolaescu writes: > Andreas Schwab writes: > > > =C3=93scar Fuentes writes: > >=20 > > > Useless for whom? For the developer who is working on the feature? = No, > > > they are small milestones and state-savers (for synchronizing his > > > desktop with his laptop, for instance). For the other developers? Y= es, > > > but that's the reason why merged history is hidden by default. > >=20 > > Such a useless commit history should never be published in the first > > place. > > And to build on your argument: if the developer decides to put something > in a log, then it must be relevant, For who? > so we should show it by default. Okay, here is a more realistic log example. A user occassionally hacks on Emacs for short periods and decided to implement a small feature: 1 created stubs for `foo' and `bar'. Call them from `zoo'. 2 merge from upstream. 3 implemented `foo'. 4 implemented `bar'. 5 implementation of `foo' was broken beyond hope. remove it. 6 merge from upstream. 7 `foo' implemeted, take two. 8 merge from upstream. 9 some code cleaning. 10 merge from upstream. For the hacker which is working on that branch, this looks as a very reasonable and informative history. But for the rest of us it is uninteresting. If you intend to set a policy that only changes which are relevant to the general community enters the history of the *private* feature branches of a given developer, or that the developer must remove the local history before sending the change upstream... well, you are throwing down the drain one of the most appreciated qualities of a dVCS: to have a VCS for personal use with the ability of integrating the final result into some other branch. Using the dVCS will be painful but, hey, `log --include-merges' will result on an impressive amount of information! :-) (Actually, under such policy, `log --include-merges' will add no information at all, except for the lon-lived branches of the kind of multi-tty, etc.) --=20 =C3=93scar