Hi Junio, On Tue, 8 Sep 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 agree that the use case in the second paragraph above does not fit > what the "force with lease" option is meant to solve. You do not > even want to be forcing in the workflow so "--force-with-anything" > is a bad name for the mode of operation, if I am reading you right. No, you _have_ to force the push. If you don't have to force the push, i.e. if it is a fast-forward, there absolutely is no need for any of this. In contrast, when you want to make sure that you _actually_ incorporated the revision that is currently the remote tip, e.g. via `git pull --rebase` with a possible additional rebase on top that makes this _not_ a fast-forward, you totally have to force the push, otherwise it won't work. Ciao, Dscho
