From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29704 invoked by alias); 24 Jan 2014 10:28:01 -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 29695 invoked by uid 89); 24 Jan 2014 10:28:00 -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,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout23.012.net.il Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jan 2014 10:27:59 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MZW00E00I5P9O00@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Fri, 24 Jan 2014 12:27:57 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZW00EPIIEK8A30@a-mtaout23.012.net.il>; Fri, 24 Jan 2014 12:27:57 +0200 (IST) Date: Fri, 24 Jan 2014 10:28: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: <83a9eleksf.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> X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00928.txt.bz2 > Date: Fri, 24 Jan 2014 10:09:06 +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. > 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. > and if they do then I no longer have a standalone > commit I can point to as "the feature was added in commit 123abc". ??? Why not? When you commit a merge, it doesn't add back the commits that were on master; you still add only your changes. The difference is that, when bisecting later, you will see that a merge introduced a bug, whereas after a rebase, that merge will no longer be visible, and it will look as if your changes alone introduced the bug. Which is a lie. > Even worse if people work on master and have a "git commit; git pull; > git push" workflow then you can get almost one merge commit per-commit > which makes browsing the history a real mess. Mess or not, that is really what happened, whereas re-written history is a lie. Again, you should be free to rebase if you like, but why can't _I_ merge instead? Why should your personal preferences constrain my workflows?