git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Alex Henrie <alexhenrie24@gmail.com>
Cc: git@vger.kernel.org, rcdailey.lists@gmail.com, newren@gmail.com,
	rsbecker@nexbridge.com, annulen@yandex.ru
Subject: Re: [PATCH v2] pull: warn if the user didn't say whether to rebase or to merge
Date: Sat, 29 Feb 2020 08:51:38 -0800	[thread overview]
Message-ID: <xmqqzhd1balh.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20200229010927.335119-1-alexhenrie24@gmail.com> (Alex Henrie's message of "Fri, 28 Feb 2020 18:09:27 -0700")

Alex Henrie <alexhenrie24@gmail.com> writes:

> +		warning(_("Pulling without specifying whether to rebase or to merge is discouraged\n"
> +			"and will be disallowed in a future Git release.\n"

Sorry for not catching this in the earlier round, but I do not think
anybody argued, let alone the community came to a concensus on
doing, such a strong move.  Am I mistaken?

I certainly did not intend to, at least when I commented on the
earlier round and proposed an updated log message, I wasn't even
aware of the possibility that we may want to turn this into die()
after a transition period.

Not that I'd object strongly to the idea, but it was somewhat
unexpected.

If we are proposing to make it a long-term plan, that should
certainly be written down in the proposed log message.

> +			"Next time, run `git config pull.rebase (true|false)` first\n"
> +			"or pass --rebase, --no-rebase, or --ff-only on the command line.\n

I am somewhat puzzled by "first, or".  You certainly mean the config
to be "set and forget", and you do not want to say "before you pull,
do this first, always", but somehow the latter is the impression I
got.

But it does not sound to me like "Next time, and only next time, do
this configuration.  You can countermand the choice you make from
the command line later if needed", which I think is what you meant
to convey to your readers.
 
    You can squelch this message by `pull.rebase` configuration
    variable to show your preference.  By passing --[no-]rebase
    or --ff-only from the command line, you can countermand the
    choice per invocation.

is what I came up with, but I am not quite happy with it.  It is
overly long to start with X-<.

"));
> +	}
> +
>  	return REBASE_FALSE;
>  }

  reply	other threads:[~2020-02-29 16:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-29  1:09 [PATCH v2] pull: warn if the user didn't say whether to rebase or to merge Alex Henrie
2020-02-29 16:51 ` Junio C Hamano [this message]
2020-02-29 21:21   ` Alex Henrie

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqzhd1balh.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=alexhenrie24@gmail.com \
    --cc=annulen@yandex.ru \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=rcdailey.lists@gmail.com \
    --cc=rsbecker@nexbridge.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).