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 > simple? > 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 workflow anyways. 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. Thanks, Jake > -- > Stefan Haller > Ableton > http://www.ableton.com/