From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32588 invoked by alias); 24 Jan 2014 10:35:27 -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 32578 invoked by uid 89); 24 Jan 2014 10:35:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f181.google.com Received: from mail-ig0-f181.google.com (HELO mail-ig0-f181.google.com) (209.85.213.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 24 Jan 2014 10:35:26 +0000 Received: by mail-ig0-f181.google.com with SMTP id j1so2198769iga.2 for ; Fri, 24 Jan 2014 02:35:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=APHHafvj6XYWvvFrlmCz29X4wi3gUj9i2289ABoEdLw=; b=A1uRKnU14jMU40M39lW5KuAtpBqpBepiBL7VwEeppEpM0hdQBiRpxu3gCS0OLr/Xpo v1Q13BM3h4sW5L83DfL+c4qOwZol6FBQgnYUnbgI7k2n/FLITmo8uI9BH+becAkRRWSB rOLpSdeiEqUhliN40nUXasWgLsADPEwkGrJ1JwzCOyJPiJAHnhmwDlVGXEcHGqEUphDE AQoakwl01Wpmqk5B7yxJURaJeSreky+74dVNcVljl0QJaJyrtOvcYhx49BoidwwM4EBP 3bmXl5+upqMqCfSLDP6UX2ZT0B29Tyg/BGH4k8CLRS3jthnamymcQ4k2HjAQQkA1erAg fNzg== X-Gm-Message-State: ALoCoQmpCO6SitAh3GME0Wh5MQIZKPykZwv/PL4OkMfKFI9QApEzilRNYXLmlQ+JeN8mh8KQwWMG MIME-Version: 1.0 X-Received: by 10.43.78.78 with SMTP id zl14mr10154640icb.5.1390559724249; Fri, 24 Jan 2014 02:35:24 -0800 (PST) Received: by 10.64.20.52 with HTTP; Fri, 24 Jan 2014 02:35:24 -0800 (PST) In-Reply-To: <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> <83a9eleksf.fsf@gnu.org> Date: Fri, 24 Jan 2014 10:35:00 -0000 Message-ID: Subject: Re: reject merges on gdb release branches? From: Will Newton To: Eli Zaretskii Cc: Joel Brobecker , ricard.wanderlof@axis.com, "gdb-patches@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00929.txt.bz2 On 24 January 2014 10:28, Eli Zaretskii wrote: >> 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. 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. >> 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. Now it is possible you mismerged and your commit is now bad, but it is still a single atomic change that can be reverted simply. I would rather deal with that than have to wade through a number of merge commits to see what cumulative effect they have. Personal preference perhaps. >> 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. Therein lies the issue though, you can only rebase in a single line of history, so you will only see the merge commit caused the problem even if it merges many commits. >> 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. Lie is rather an emotive term don't you think? > 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? As I said, it's not about the committer, it's about the future readers of the history. -- Will Newton Toolchain Working Group, Linaro