From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933698Ab2AKC2g (ORCPT ); Tue, 10 Jan 2012 21:28:36 -0500 Received: from b-pb-sasl-quonix.pobox.com ([208.72.237.35]:46373 "EHLO smtp.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757035Ab2AKC2f (ORCPT ); Tue, 10 Jan 2012 21:28:35 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=U1X1J/hjLOPaxESq/G2QsUbo6hU/gnBn FWlkKGYSv8KjNCKdd/E3IZ9aei41sv6pJQXrTKosJtq+j6mBH1ydV4KXWg0Rttb2 ZmUme64MzvhyQsx5U+wUg3n6+F1Un8gnZ871pcUxs5E2J2iyZbAwJdDFh2EwnIgI zWijQOmoRIo= From: Junio C Hamano To: Linus Torvalds Cc: Mark Brown , Liam Girdwood , linux-kernel@vger.kernel.org, Git Mailing List Subject: Re: Regulator updates for 3.3 References: <20120109073727.GF22134@opensource.wolfsonmicro.com> <20120110184530.GE7164@opensource.wolfsonmicro.com> <20120110222711.GK7164@opensource.wolfsonmicro.com> Date: Tue, 10 Jan 2012 18:28:32 -0800 In-Reply-To: (Linus Torvalds's message of "Tue, 10 Jan 2012 14:54:27 -0800") Message-ID: <7vmx9v7z1r.fsf@alter.siamese.dyndns.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Pobox-Relay-ID: F55ED0DE-3BFB-11E1-8BC7-9DB42E706CDE-77302942!b-pb-sasl-quonix.pobox.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds writes: > Addid junio and git to the cc just to bring up this issue of bad UI > once again. I realize it could break old scripts to start up an editor > window, but still.. It is a non-starter to unconditionally start an editor. We would need a good way for users to conveniently say "I am doing this unusual merge that needs to be justified, and I want an editor to write my justification". Obviously, "git merge -e regulator/for-linus" would work and is just three keystrokes, which can be said "convenient enough" once the user gets used to, but I think this is still inadequate as a solution, as the real problem is it is _too_ easy to forget to give the option. Until the user becomes _aware_ of the issues, it will not even occur to the user that s/he _has_ to justify a merge (or not create a merge at all) in certain circumstances and directions. After all, you have been repeating the "do not make meaningless merges" for the past five years on the list. UI tweak alone will not fix that. If we are to rely on user's conscious action, I think it may be something like a set of configurations that say things like: - This branch is for advancing a specific topic, and not for merging random development that happen elsewhere; - This branch is for merging works by people downstream from me; - This remote tracking branch (and by extension that branch at that remote that uses this as its remote tracking branch) is my upstream and I should not be merging back from it; and - This remote tracking branch is my downstream, and I should freely merge it when I heard it is ready. and depending on the combination of what is being merged into what, toggle the --edit option by default for "git merge" when neither "--edit" nor "--no-edit" is given, just like "git merge" defaults to "--edit" when merging an annotated tag.