On Sat, Apr 8, 2017 at 2:29 AM, Jeff King <peff@xxxxxxxx> wrote: > On Sat, Apr 08, 2017 at 09:35:04AM +0200, Ævar Arnfjörð Bjarmason wrote: > >> Is it correct that you'd essentially want something that works like: >> >> git push --force-with-lease=master:master origin master:master > > I don't think that would do anything useful. It would reject any push > where the remote "master" is not the same as your own master. And of > course if they _are_ the same, then the push is a noop. > >> 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. > > The point of the --force-with-lease feature is that you would mark a > point in time where you started some rewind-y operation (like a rebase), > and at the end you would want to make sure nobody had moved the remote > ref when you push over it (which needs to be a force because of the > rewind). > > 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 > > That final operation will fail if somebody else pushed in the meantime. > But obviously this workflow is a pain, because you have to manually mark > the start of the unsafe operation with a tag. > > If you haven't fetched in the meantime, then origin/master is a good > approximation of "base". But if you have fetched, then it is worthless. > > It would be nice if we could automatically deduce the real value of > base. I don't think we could do it in a foolproof way, but I wonder if > we could come close in some common circumstances. For instance, imagine > that unsafe operations like rebase would note that "master" has an > upstream of "origin/master", and would record a note saying "we took a > lease for origin/master at sha1 X". > > One trouble with that is that you may perform several unsafe operations. > For example, imagine it takes you multiple rebases to achieve your final > state: > > git fetch > git rebase -i master > git rebase -i master > git push --force-with-lease=master > > and that --force-with-lease now defaults to whatever lease-marker is > left by rebase. Which marker should it respect? If the second one, then > it's unsafe. But if the first one, then how do we deal with stale > markers? > > Perhaps it would be enough to reset the markers whenever the ref is > pushed. I haven't thought it through well enough to know whether that > just hits more corner cases. > > -Peff 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? However, I think using origin/master works fine as long as you don't auto-fetch. If you're doing it right, you can handle origin/master updates by checking that your rewind-y stuff is correct for the new origin/master RIGHT before you push. The tricky part here is that you have to remember to check after every fetch before you push. This is why I would always create my own tag or lease reference prior to the use. 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.. Thanks, Jake