From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30076 invoked by alias); 24 Jan 2014 08:54: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 30061 invoked by uid 89); 24 Jan 2014 08:54:37 -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: mtaout22.012.net.il Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jan 2014 08:54:36 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MZW00700E2KUU00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Fri, 24 Jan 2014 10:54:33 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZW0077VE2XNP60@a-mtaout22.012.net.il>; Fri, 24 Jan 2014 10:54:33 +0200 (IST) Date: Fri, 24 Jan 2014 08:54:00 -0000 From: Eli Zaretskii Subject: Re: reject merges on gdb release branches? In-reply-to: <20140124080703.GL4762@adacore.com> To: Joel Brobecker Cc: ricard.wanderlof@axis.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83eh3xep43.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> X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00920.txt.bz2 > Date: Fri, 24 Jan 2014 12:07:03 +0400 > From: Joel Brobecker > Cc: Ricard Wanderlof , > gdb-patches@sourceware.org > > I think we cannot expect all our contributors to know git well, and > for those who don't have a good command of that tool, branch merges > are more difficult to understand than simple commits. But this sounds backwards. Merging from a branch is a single git command, while rebasing requires much more, and requires also understanding of what rebasing means and does. We are actually requiring contributors to know more of git, not less. Also, isn't git popularity enough for us to not be afraid so much? In any case, if we fear mistakes by git newbies, why not have a Wiki page that explains the recommended workflow and commands, and point contributors to that when they get write access. > Rejecting merges makes sure that the history remains linear. This is a strange argument: if we want linear history, why did we switch to git at all? dVCS make very little sense, if we want linear history. What am I missing? > I still do not understand what the problem is with rebasing though. > You said "loss of information". Can you explain a bit more? The non-linear parts of the development history are deleted. You can no longer tell which other branches contributed to a particular commit. For example, if a bug happened because you merged from master half way through feature development, you can no longer see that merge. This is an important part of the development history, and is sometimes invaluable when reflecting on past experience or analyzing bugs. I don't see why we should force everyone lose it. In effect, rebasing is tantamount to preparing diffs, then applying those diffs on the tip of the master branch: you keep all the textual changes, but lose the DAG of the flow that led to them. Again, if we don't care at all about all this, why did we switch to git? It sounds like we want a strictly centralized development, which means about 99% of power of git (or any dVCS, actually) is left off limits for us. Is that really the intent?