Re: Tools that do an automatic fetch defeat "git push --force-with-lease"
- Date: Sat, 8 Apr 2017 05:29:10 -0400
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: Tools that do an automatic fetch defeat "git push --force-with-lease"
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
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
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
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.