Re: [PATCH] push: make `--force-with-lease[=<ref>]` safer

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 9, 2020, 03:40 UTC
Message-ID: <nycvar.QRO.7.76.6.2009090525120.54@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqwo14z2de.fsf@gitster.c.googlers.com>

Hi Junio,

On Tue, 8 Sep 2020, Junio C Hamano wrote:

Show 22 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Now, to be honest, I thought that this mode would merit a new option
> > rather than piggy-backing on top of `--force-with-lease`. The reason is
> > that `--force-with-lease` targets a slightly different use case than mine:
> > it makes sure that we do not overwrite remote refs unless we already had a
> > chance to inspect them.
> >
> > In contrast, my workflow uses `git pull --rebase` in two or more separate
> > worktrees, e.g. when developing a patch on two different Operating
> > Systems, I frequently forget to pull (to my public repository) on one
> > side, and I want to avoid force-pushing in that case, even if VS Code (or
> > I, via `git remote update`) fetched the ref (but failing to rebase the
> > local branch on top of it).
> >
> > So I think that the original `--force-with-lease` and the mode you
> > implemented target subtly different use cases that are both valid, and
> > therefore I would like to request a separate option for the latter.
>
> I tend to agree that that particular use case does not fit what the
> "force with lease" option is meant to solve.  It should be a different
> option, as you do not even want to be forcing.

Actually, I _do_ want to be forcing, but _only_ if the recorded remote tip has been integrated into the local branch at some point (even if it has been rebased or amended away).

And even then, I want to only force when the recorded remote tip still matches the actual remote tip, i.e. I want to force "with lease".

> But probably I am not getting your use case well enough to give a
> good name suggestion.  "git push" without any form of "force" would
> safely fail in your "I rebased on one side, and the other one is now
> out of sync" situation already, so...

Yes, it would safely fail, but it would also fail in situations where I do _not_ want it to fail.

Imagine that you and I work together on a patch series, and we actually share the same public repository. Let's say that we also want to allow for some crossing emails that might be missed by the other when pushing our changes.

Since we are working on a patch series, there will be a lot of amending and rewording and rebasing going on.

So let's assume that you just did another round of amending and rewording and want to push the branch. What you will want to avoid is to overwrite commits that I might have just pushed. `--force-with-lease` to the rescue!

Since you did not fetch in between pulling and amending, that is safe.

But what if, maybe even by mistake, you called `git fetch` in between? And then you _did_ get my updates, but only in the remote-tracking branch (the "lease"), yet those updates never made it into the local branch. And since `git push --force-with-lease` did not fail, you failed to notice that I had made some edits, didn't `range-diff` and took care of amending your local changes accordingly, and therefore you overwrote my changes.

That is the scenario this new mode wants to address.

Note that a similar scenario can occur if you work on a patch series on Linux, then push it to your public repository, then try to make it work on, say, an HP/UX machine you happen to have access to (maybe because your employer needs you to make sure that this particular patch series solves a particular problem on that particular machine), and you need to amend the changes there. If you're very disciplined, you will only work on one machine until you're done, then push, then fetch on the other machine. However, if you're less disciplined (or "just need to check out something real quick on the other machine"), this new mode will come in quite handy.

Ciao, Dscho