Hi, On Wed, 9 Sep 2020, Johannes Schindelin wrote: > 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. Maybe `--force-if-incorporated`? Originally, I had in mind to call it `--safe-force`, but that might be too vague. BTW I think the patch needs to cover a bit more, still: after I run `git pull --rebase`, the local branch will never have been at the same revision as the fetched one: `git rebase` moves to an unnamed branch before replaying the patches. So I think we need to see whether the remote tip was _reachable_ from (not necessarily identical to) any of the reflog's revisions. Ciao, Dscho
