All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Henrie <alexhenrie24@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Phillip Wood <phillip.wood123@gmail.com>,
	git@vger.kernel.org, git@matthieu-moy.fr, christiwald@gmail.com,
	john@keeping.me.uk, philipoakley@iee.email
Subject: Re: [PATCH 0/2] advise about force-pushing as an alternative to reconciliation
Date: Wed, 5 Jul 2023 20:32:56 -0600	[thread overview]
Message-ID: <CAMMLpeRPcw8WbGJwbeS_E+qxKvCukNc3g-3BXeNP5BrRJJ5ifA@mail.gmail.com> (raw)
In-Reply-To: <xmqq5y6z3oym.fsf@gitster.g>

On Tue, Jul 4, 2023 at 11:30 PM Junio C Hamano <gitster@pobox.com> wrote:

> I think the description in the cover was prone to be misunderstood,
> but I think I got it now.  Where you are pushing from your topic
> branch is your "publishing" branch that only you would push into,
> and the primary way you update it is by rebasing your local copy of
> it on the updated 'master' branch to keep up with others' work
> integrated into the shared 'master'.

Right. It's a narrow case, but it's quite common. For example, GitHub
and GitLab keep permanent references to every version of a branch that
was pushed while a pull request was open for that branch. On those
platforms, force-pushing is analogous to emailing a new version of a
patchset.

> In such a workflow, the way to update your "publishing" branch will
> normally be to force push to overwrite.  And in this very narrow use
> case, where nobody else is pushing into your "publishing" branch,
> your remote-tracking branch would be always up-to-date with the
> remote repository and use of --force-with-lease that does not say
> which commit you expect there to be is safe.  In fact, you do not
> even have to use --force-with-lease in such a use case, because its
> additional safety (relative to --force) relies on the assumption
> that you would be the only one who is pushing into the remote
> repository to update that branch---and at that point, --force
> without lease is just as good.

OK, I'll switch back to --force in v3. Thanks for the feedback!

-Alex

  reply	other threads:[~2023-07-06  2:33 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 [this message]
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
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=CAMMLpeRPcw8WbGJwbeS_E+qxKvCukNc3g-3BXeNP5BrRJJ5ifA@mail.gmail.com \
    --to=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.wood123@gmail.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 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.