All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Alex Henrie <alexhenrie24@gmail.com>,
	git@vger.kernel.org, git@matthieu-moy.fr, christiwald@gmail.com,
	john@keeping.me.uk, philipoakley@iee.email, gitster@pobox.com,
	phillip.wood@dunelm.org.uk
Subject: Re: [PATCH v3 2/2] push: advise about force-pushing as an alternative to reconciliation
Date: Fri, 7 Jul 2023 09:49:22 +0100	[thread overview]
Message-ID: <82255166-49ac-3c10-1744-27d6d436822e@gmail.com> (raw)
In-Reply-To: <20230706040111.81110-3-alexhenrie24@gmail.com>

Hi Alex

On 06/07/2023 05:01, Alex Henrie wrote:
> Also, don't put `git pull` in an awkward parenthetical, because
> `git pull` can always be used to reconcile branches and is the normal
> way to do so.

This message would also benefit from adding explanation as to why this 
change is desirable.

> Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
> ---
>   builtin/push.c | 27 +++++++++++++++------------
>   1 file changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/builtin/push.c b/builtin/push.c
> index 6f8a8dc711..b2f0a64e7c 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -301,21 +301,24 @@ static void setup_default_push_refspecs(int *flags, struct remote *remote)
>   
>   static const char message_advice_pull_before_push[] =
>   	N_("Updates were rejected because the tip of your current branch is behind\n"
> -	   "its remote counterpart. Integrate the remote changes (e.g.\n"
> -	   "'git pull ...') before pushing again.\n"
> +	   "its remote counterpart. Use 'git pull' to integrate the remote changes\n"

This is much clearer than "(e.g. 'git pull ...')"

> +	   "before pushing again, or use 'git push --force' to delete the remote\n"
> +	   "changes and replace them with your own.\n"

I think it would be good to give a bit more context here as to when 
force pushing is a good idea. For example something like

     If you have rebased the branch since you last integrated remote
     changes then you can use
     'git push --force-with-lease=<branch-ref> --force-if-includes' to
     safely replace the remote branch.

     If you have deleted and then recreated the branch since you last
     integrated remote changes then you can use 'git push +<branch>' to
     replace the remote. Note that if anyone else has pushed work to
     this branch it will be deleted.

It makes the advice longer  but the user get a specific suggestion for 
their current situation rather than a generic suggestion to delete the 
remote changes without discussing the implications. In this case we know 
that it was the current branch that was rejected and so should fill in 
the branch name in the advice as well.

My main issue with the changes in this series is that they seem to 
assume the user is (a) pushing a single branch and (b) they are the only 
person who works on that branch. That is a common but narrow case where 
force pushing is perfectly sensible but there are many other scenarios 
where suggesting "push --force" would not be a good idea.

Best Wishes

Phillip

>   	   "See the 'Note about fast-forwards' in 'git push --help' for details.");
>   
>   static const char message_advice_checkout_pull_push[] =
>   	N_("Updates were rejected because a pushed branch tip is behind its remote\n"
> -	   "counterpart. Check out this branch and integrate the remote changes\n"
> -	   "(e.g. 'git pull ...') before pushing again.\n"
> +	   "counterpart. Check out this branch and use 'git pull' to integrate the\n"
> +	   "remote changes before pushing again, or use 'git push --force' to delete\n"
> +	   "the remote changes and replace them with your own.\n"
>   	   "See the 'Note about fast-forwards' in 'git push --help' for details.");
>   
>   static const char message_advice_ref_fetch_first[] =
> -	N_("Updates were rejected because the remote contains work that you do\n"
> -	   "not have locally. This is usually caused by another repository pushing\n"
> -	   "to the same ref. You may want to first integrate the remote changes\n"
> -	   "(e.g., 'git pull ...') before pushing again.\n"
> +	N_("Updates were rejected because the remote contains work that you do not\n"
> +	   "have locally. This is usually caused by another repository pushing to\n"
> +	   "the same ref. Use 'git pull' to integrate the remote changes before\n"
> +	   "pushing again, or use 'git push --force' to delete the remote changes\n"
> +	   "and replace them with your own.\n"
>   	   "See the 'Note about fast-forwards' in 'git push --help' for details.");
>   
>   static const char message_advice_ref_already_exists[] =
> @@ -327,10 +330,10 @@ static const char message_advice_ref_needs_force[] =
>   	   "without using the '--force' option.\n");
>   
>   static const char message_advice_ref_needs_update[] =
> -	N_("Updates were rejected because the tip of the remote-tracking\n"
> -	   "branch has been updated since the last checkout. You may want\n"
> -	   "to integrate those changes locally (e.g., 'git pull ...')\n"
> -	   "before forcing an update.\n");
> +	N_("Updates were rejected because the tip of the remote-tracking branch has\n"
> +	   "been updated since the last checkout. Use 'git pull' to integrate the\n"
> +	   "remote changes before pushing again, or use 'git push --force' to delete\n"
> +	   "the remote changes and replace them with your own.\n");
>   
>   static void advise_pull_before_push(void)
>   {

  reply	other threads:[~2023-07-07  8:49 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
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 [this message]
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=82255166-49ac-3c10-1744-27d6d436822e@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=alexhenrie24@gmail.com \
    --cc=christiwald@gmail.com \
    --cc=git@matthieu-moy.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=john@keeping.me.uk \
    --cc=philipoakley@iee.email \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.