git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Liam Girdwood <lrg@ti.com>,
	linux-kernel@vger.kernel.org,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Regulator updates for 3.3
Date: Tue, 10 Jan 2012 18:47:55 -0800	[thread overview]
Message-ID: <CA+55aFx5NATrpLnkMiV2vAxSAJPK7wkY2vyHbyeZGgT9+jP06w@mail.gmail.com> (raw)
In-Reply-To: <7vmx9v7z1r.fsf@alter.siamese.dyndns.org>

On Tue, Jan 10, 2012 at 6:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> It is a non-starter to unconditionally start an editor.

I really wonder. Because not being default will always lead to really
odd ways of saying "it should have been default, so we'll make up
these complex and arbitrary special rules" (like the ones you were
starting to outline).

So I really suspect it would be easier and more straightforward to
instead just bite the bullet, and say:

 (a) start an editor by default if both stdin/stdout matched in fstat
and were istty().

 (b) have some trivial way to disable that default behavior for people
who really want the legacy behavior. And by "trivial" I mean "set the
GIT_LEGACY_MERGE environment variable" or something.

 (c) have a "--no-editor" command line switch so that scripts and/or
users that want to make it explicit (rather than rely on the hacky
legacy workaround) can do so (and a explicit "--editor" switch to
enable people to use a GUI editor even if they aren't on a terminal -
think something IDE environment, whatever).

Where (a) is so that people will always get the editor if they aren't
aware of it, and (b) is so that existing scripting environments can
then *trivially* work around the fact that we changed semantics,
including on a site-wide basis. With (c) being for future users. Of
course, just a "git merge < /dev/null" would also do it, but sounds
ridiculously hacky (and doesn't allow the "--editor" version), so that
"--no-editor" flag sounds saner and much more powerful.

Of course, if you use "-m", no editor would fire up anyway, exactly
like with "git commit", so that's one way to avoid the issue forever
(and be backwards compatible). But if you actually *want* to get the
auto-generated message and no editor, that would need that new switch.

Yes, git has been very good about not breaking semantics. But it's
happened before too when it needed to happen. We've had much bigger
breaks (like the whole "git-xyz" to "git xyz" transition, for example,
which broke a lot of scripts).

                       Linus

  reply	other threads:[~2012-01-11  2:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20120109073727.GF22134@opensource.wolfsonmicro.com>
     [not found] ` <CA+55aFyhoh0rT_ujuE1w3RpuR7kqivYFwPpm66VC-xtq1PiGUQ@mail.gmail.com>
     [not found]   ` <20120110184530.GE7164@opensource.wolfsonmicro.com>
     [not found]     ` <CA+55aFxXb7wqfrpozS6iH0k25y-+Uy8_Tavv59JXMhaWrjXLaw@mail.gmail.com>
     [not found]       ` <20120110222711.GK7164@opensource.wolfsonmicro.com>
2012-01-10 22:54         ` Regulator updates for 3.3 Linus Torvalds
2012-01-10 23:17           ` Mark Brown
2012-01-11  2:28           ` Junio C Hamano
2012-01-11  2:47             ` Linus Torvalds [this message]
2012-01-11  3:03               ` Junio C Hamano
2012-01-11  3:14                 ` Linus Torvalds
2012-01-11  6:59                   ` Re* " Junio C Hamano
2012-01-11 16:14                     ` Phil Hord
2012-01-11 16:23                     ` Linus Torvalds
2012-01-16  0:14                     ` Pete Harlan
2012-01-16 23:33                       ` Junio C Hamano
2012-01-16 23:43                         ` Martin Fick
2012-01-17  5:33                         ` Pete Harlan
2012-01-17  6:13                           ` Junio C Hamano
2012-01-11  3:21                 ` Linus Torvalds
2012-01-11 18:40           ` Paul Gortmaker
2012-01-13 19:12             ` [PATCH] merge: Make merge strategy message follow the diffstat Junio C Hamano
2012-01-13 19:27               ` Nguyen Thai Ngoc Duy
2012-01-13 19:49                 ` Linus Torvalds
2012-01-17  8:03                   ` Miles Bader

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+55aFx5NATrpLnkMiV2vAxSAJPK7wkY2vyHbyeZGgT9+jP06w@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).