From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12426 invoked by alias); 24 Jan 2014 10:48:38 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 12412 invoked by uid 89); 24 Jan 2014 10:48:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout25.012.net.il Received: from mtaout25.012.net.il (HELO mtaout25.012.net.il) (80.179.55.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jan 2014 10:48:37 +0000 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0MZW00O00ITK0900@mtaout25.012.net.il> for gdb-patches@sourceware.org; Fri, 24 Jan 2014 12:48:20 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZW00JACJCJZS60@mtaout25.012.net.il>; Fri, 24 Jan 2014 12:48:20 +0200 (IST) Date: Fri, 24 Jan 2014 10:48:00 -0000 From: Eli Zaretskii Subject: Re: reject merges on gdb release branches? In-reply-to: To: Will Newton Cc: brobecker@adacore.com, ricard.wanderlof@axis.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <838uu5eju2.fsf@gnu.org> References: <20140122051133.GB4762@adacore.com> <83r480f2r2.fsf@gnu.org> <20140122161520.GF4762@adacore.com> <83bnz4ezst.fsf@gnu.org> <83wqhqekpp.fsf@gnu.org> <83ha8tersb.fsf@gnu.org> <20140124080703.GL4762@adacore.com> <83eh3xep43.fsf@gnu.org> <83a9eleksf.fsf@gnu.org> X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00930.txt.bz2 > Date: Fri, 24 Jan 2014 10:35:24 +0000 > From: Will Newton > Cc: Joel Brobecker , ricard.wanderlof@axis.com, "gdb-patches@sourceware.org" > > >> The problem with merge commits is they make the history noisy. If I > >> have a long running development branch I could have lots of: > >> > >> Merge branch 'master' > > > > That's easy enough to skip, if you aren't interested (I am). I don't > > see any real problem here, any development history has some amount of > > noise if you are looking for certain things and aren't interested in > > others. > > That's fine if you have one or two, but in the degenerate case you may > have half your commit history being merges. It's simply not helpful to > anyone. It is helpful to anyone who wishes to understand the sequence of events that led to a certain line being what it is. Merges are in important part of that. E.g., suppose that a merge produced a conflict whose resolution mistakenly introduced a bug. If you eliminate the merge, you will be unable to understand the reasons for the buggy change, at least not easily. > >> Commits that don't serve any function. Yes, they mark that I merged > >> master at that point, but if the changes do not interact with mine > >> that is irrelevant > > > > In many, if not most, cases you will not know if they interact or > > don't. Once you've rewritten that part of history, it is lost > > forever, even if you later need it. > > The history is not lost, the history is all present. Essentially you > have done the merge yourself (as part of the rebase) and squashed the > merge into the functional commit. Yes, and the information in the squashed part is lost. Anyway, we are going in circles. I'm not trying to convince you to change your workflow, I'm asking to allow me to keep mine.