On Sat, Apr 8, 2017 at 3:13 PM, Jeff King <p...@peff.net> wrote: > 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. >
Well, if we don't mind backwards compatibility breaking, we could require that uesrs run create-lease, and refuse to accept anything that isn't a lease ref? That would force the user to have created a lease which should help? But that IS backwards incompatible... >> 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 Yea, I agree this sort of direction is nicer. Thanks, Jake
