Re: Tools that do an automatic fetch defeat "git push --force-with-lease"
- Date: Sat, 8 Apr 2017 09:35:04 +0200
- From: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
- Subject: Re: Tools that do an automatic fetch defeat "git push --force-with-lease"
On Sat, Apr 8, 2017 at 4:15 AM, Matt McCutchen <matt@xxxxxxxxxxxxxxxxx> wrote:
> When I'm rewriting history, "git push --force-with-lease" is a nice
> safeguard compared to "git push --force", but it still assumes the
> remote-tracking ref gives the old state the user wants to overwrite.
> Tools that do an implicit fetch, assuming it to be a safe operation,
> may break this assumption. In the worst case, Visual Studio Code does
> an automatic fetch every 3 minutes by default , making
> --force-with-lease pretty much reduce to --force.
> For a safer workflow, "git push" would check against a separate "old"
> ref that isn't updated by "git fetch", but is updated by "git push" the
> same way the remote-tracking ref is and maybe also by commands that
> update the local branch to take into account remote changes (I'm not
> sure what reasonable scenarios there are, if any). Has there been any
> work on this? I can write a wrapper script for the simple case of "git
> push" of a single branch to the same branch on a remote, which is
> pretty much all I use right now, but a native implementation would
> support all of the command-line usage forms, which would be nice.
> Thanks for reading!
Is it correct that you'd essentially want something that works like:
git push --force-with-lease=master:master origin master:master
As opposed to the current:
git push --force-with-lease=master:origin/master origin master:master
Which is how the default:
git push --force-with-lease
Works now, assuming you're on the master branch with correct tracking info.
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.
Junio implemented this in v22.214.171.124-736-g28f5d17611 & noted in that
commit that the current semantics may not be a sensible default. I
think looking at the local ref instead of the remote tracking ref
would be a better default.