Re: Tools that do an automatic fetch defeat "git push --force-with-lease"
- Date: Mon, 10 Apr 2017 01:08:27 -0700
- From: Jacob Keller <jacob.keller@xxxxxxxxx>
- Subject: Re: Tools that do an automatic fetch defeat "git push --force-with-lease"
On Sun, Apr 9, 2017 at 4:00 AM, Stefan Haller <haller@xxxxxxxxxxx> wrote:
> Jacob Keller <jacob.keller@xxxxxxxxx> wrote:
>> Agreed. You "take" a lease whenever you push to the remote or when you
>> pull from the remote and when you pull into the branch. It should
>> store something that tracks both the branch and remote branch together
>> so that you can generalize it to multiple remotes.
> I don't see why it has to support multiple remotes (but then I don't
> have much experience with workflows involving multiple remotes, so I may
> well be missing something). A local branch can only have one remote
> tracking branch on one remote, and in my view --force-with-lease without
> arguments works with that remote tracking branch only. Is this view too
I think that's fine. Thinking in terms of only one remote at a time is easier.
>> It doesn't necessarily track perfectly with a branch that contains
>> extra work such as when doing pull --rebase, but maybe you have an
>> idea about that?
> Maybe I wasn't clear enough about that in my proposal, but I propose to
> always store the commit hash of the remote tracking branch as a new
> lease after push and pull, not the local branch. This way it works
> nicely with pull --rebase and a branch that has extra local commits.
Oh right. The main thing it doesn't give is that this doesn't enforce
that your local branch *has* to have at one point prior to the push
matched the remote branch that you're overwriting, which would be even
more evidence that your changes are what you expect and aren't
deleting anything unexpectedly. However, I think that's not strictly
necessary to require that since it would also break pull-rebase
So something like:
For a branch, also store its last known "lease" sha1 value, which
updates once every time that we push that branch to the remote
tracking branch or any time that we pull into the branch using the
remote tracking branch.
This value is what we would default to, and we only need to store the
latest one, since that's the last known good value. If the value is
wrong then we will error and avoid deleting work, and if it's correct,
then we know that the remote branch is correct for this specific push
and is safe.
I think this is straight forward and reasonable approach to solve the
problem, and makes using force-with-lease much nicer.
> Stefan Haller