git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Alex Henrie <alexhenrie24@gmail.com>
Cc: git@vger.kernel.org, git@matthieu-moy.fr, christiwald@gmail.com,
	john@keeping.me.uk, philipoakley@iee.email,
	phillip.wood123@gmail.com, phillip.wood@dunelm.org.uk
Subject: Re: [PATCH v3 1/2] remote: advise about force-pushing as an alternative to reconciliation
Date: Wed, 12 Jul 2023 08:18:10 -0700	[thread overview]
Message-ID: <xmqqo7khupjh.fsf@gitster.g> (raw)
In-Reply-To: <CAMMLpeTNMaVk7M2nLSJJzDMWPDVdyOr27Ae2-Usky5tW-dRqJQ@mail.gmail.com> (Alex Henrie's message of "Tue, 11 Jul 2023 22:47:00 -0600")

Alex Henrie <alexhenrie24@gmail.com> writes:

> Just to be sure that we're on the same page, when I said "I thought we
> just agreed that we don't need to mention force-pushing..." and you
> replied "I do not think so", were you only saying that you think that
> changes to `git commit` are essential, or were you also saying that we
> have not come to an agreement about whether to include force-pushing
> advice in this message?

None of the above ;-)

With that "I do not think so", I meant that I do not agree with "I
guess you're saying that we'd still be over-encouraging `git pull`"
that was in your message.  In the message you were responding to, I
was saying that the time the user runs `git commit` is not a good
time for the user to decide how to eventually update the remote
target, and it does not matter which one we encourage more between
"`git pull [--rebase]` then `git push`" and "`git push --force`".

I am fine dropping patch [1/2]; we would not be touching output from
"git status", "git commit", or "git checkout", and "we should not
talk about 'git pull' (or how the eventual remote update should go,
for that matter) when we notice that the base of the user's branch
has become stale" becomes totally out of the scope of this topic.  I
think that we all are in agreement that [2/2] is the more important
part of this topic, as it more directly improves the guidance for
the end-users when their "push" triggers the non-ff check.

Thanks.

  reply	other threads:[~2023-07-12 15:19 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-02 20:08 [PATCH 0/2] advise about force-pushing as an alternative to reconciliation Alex Henrie
2023-07-02 20:08 ` [PATCH 1/2] remote: " Alex Henrie
2023-07-02 20:08 ` [PATCH 2/2] push: " Alex Henrie
2023-07-03 15:33 ` [PATCH 0/2] " Phillip Wood
2023-07-03 16:26   ` Alex Henrie
2023-07-04 21:44   ` Junio C Hamano
2023-07-04 22:24     ` Alex Henrie
2023-07-05  5:30       ` Junio C Hamano
2023-07-06  2:32         ` Alex Henrie
2023-07-04 19:47 ` [PATCH v2 " Alex Henrie
2023-07-04 19:47   ` [PATCH v2 1/2] remote: " Alex Henrie
2023-07-04 21:51     ` Junio C Hamano
2023-07-04 22:41       ` Alex Henrie
2023-07-04 19:47   ` [PATCH v2 2/2] push: " Alex Henrie
2023-07-06  4:01   ` [PATCH v3 0/2] " Alex Henrie
2023-07-06  4:01     ` [PATCH v3 1/2] remote: " Alex Henrie
2023-07-06 20:25       ` Junio C Hamano
2023-07-06 20:40         ` Junio C Hamano
2023-07-06 23:23           ` Alex Henrie
2023-07-07 17:35             ` Junio C Hamano
2023-07-07 17:52             ` Junio C Hamano
2023-07-08 18:55               ` Alex Henrie
2023-07-09  1:38                 ` Junio C Hamano
2023-07-10  4:44                   ` Alex Henrie
2023-07-11  0:55                     ` Junio C Hamano
2023-07-12  4:47                       ` Alex Henrie
2023-07-12 15:18                         ` Junio C Hamano [this message]
2023-07-13  4:09                           ` Alex Henrie
2023-07-07  8:48       ` Phillip Wood
2023-07-06  4:01     ` [PATCH v3 2/2] push: " Alex Henrie
2023-07-07  8:49       ` Phillip Wood
2023-07-07 18:44         ` Junio C Hamano
2023-07-08 18:56         ` Alex Henrie
2023-07-11 18:33           ` Phillip Wood
2023-07-12  4:47             ` Alex Henrie
2023-07-12  4:55               ` Alex Henrie
2023-07-07  5:42     ` [PATCH v4 0/2] " Alex Henrie
2023-07-07  5:42       ` [PATCH v4 1/2] remote: " Alex Henrie
2023-07-07  5:42       ` [PATCH v4 2/2] push: " Alex Henrie
2023-07-13  4:41       ` [PATCH v5 0/3] don't imply that integration is always required before pushing Alex Henrie
2023-07-13  4:41         ` [PATCH v5 1/3] wt-status: don't show divergence advice when committing Alex Henrie
2023-07-13  4:41         ` [PATCH v5 2/3] remote: don't imply that integration is always required before pushing Alex Henrie
2023-07-13  4:41         ` [PATCH v5 3/3] push: " Alex Henrie
2023-07-13  9:51         ` [PATCH v5 0/3] " Phillip Wood
2023-07-13 16:15           ` Junio C Hamano

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=xmqqo7khupjh.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=alexhenrie24@gmail.com \
    --cc=christiwald@gmail.com \
    --cc=git@matthieu-moy.fr \
    --cc=git@vger.kernel.org \
    --cc=john@keeping.me.uk \
    --cc=philipoakley@iee.email \
    --cc=phillip.wood123@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    /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).