On Sat, Apr 08, 2017 at 09:35:04AM +0200, Ævar Arnfjörð Bjarmason wrote: > Is it correct that you'd essentially want something that works like: > > git push --force-with-lease=master:master origin master:master I don't think that would do anything useful. It would reject any push where the remote "master" is not the same as your own master. And of course if they _are_ the same, then the push is a noop. > I haven't used this feature but I'm surprised it works the way it > does, as you point out just having your remote refs updated isn't a > strong signal for wanting to clobber whatever that ref points to. The point of the --force-with-lease feature is that you would mark a point in time where you started some rewind-y operation (like a rebase), and at the end you would want to make sure nobody had moved the remote ref when you push over it (which needs to be a force because of the rewind). So the best way to use it is something like: git fetch ;# update 'master' from remote git tag base master ;# mark our base point git rebase -i master ;# rewrite some commits git push --force-with-lease=master:base master:master That final operation will fail if somebody else pushed in the meantime. But obviously this workflow is a pain, because you have to manually mark the start of the unsafe operation with a tag. If you haven't fetched in the meantime, then origin/master is a good approximation of "base". But if you have fetched, then it is worthless. It would be nice if we could automatically deduce the real value of base. I don't think we could do it in a foolproof way, but I wonder if we could come close in some common circumstances. For instance, imagine that unsafe operations like rebase would note that "master" has an upstream of "origin/master", and would record a note saying "we took a lease for origin/master at sha1 X". One trouble with that is that you may perform several unsafe operations. For example, imagine it takes you multiple rebases to achieve your final state: git fetch git rebase -i master git rebase -i master git push --force-with-lease=master and that --force-with-lease now defaults to whatever lease-marker is left by rebase. Which marker should it respect? If the second one, then it's unsafe. But if the first one, then how do we deal with stale markers? Perhaps it would be enough to reset the markers whenever the ref is pushed. I haven't thought it through well enough to know whether that just hits more corner cases. -Peff