On Sat, Apr 08, 2017 at 02:54:29PM -0700, Jacob Keller wrote: > > 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 > [...] > > What if we added a separate command something like: > > git create-lease > > which you're expected to run at the start of a rewind-y operation and > it creates a tag (or some other ref like a tag but in a different > namespace) which is used by force-with-lease? So then you replace that "git tag" command above with "git create-lease". I think it's an incremental improvement because it would probably record which branch you're leasing. But I think the more important issue is that the user needs to remember to take the lease in the first place. A create-lease command doesn't help that. > It might be possible to generate these lease tags prior to operations > which modify history and then maybe having a way to list them so you > can select which one you meant when you try to use force-with-lease.. So yeah, I think that is the more interesting direction. I hadn't considered resolving the multiple-operation ambiguity at push time. But I guess it would be something like "you did a rebase on sha1 X at time T, and then one on Y at time T+N", and you pick which one you're expecting. Or maybe it could even cull old leases that are still ancestors of your push (so old, already-pushed rebases aren't mentioned). I suspect that ends up being equivalent to "clear the leases when you push". And I think that may be converging on the "integrate" refs that Stefan is talking about elsewhere (or some isomorphism of it). -Peff