On Sun, Apr 9, 2017 at 1:38 AM, Stefan Haller <li...@haller-berlin.de> wrote: > Jacob Keller <jacob.kel...@gmail.com> wrote: > >> 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? > > The problem with this is that it doesn't help to use "git create-lease" > right before you start your rewind-y operation, because by that time you > may already have fetched. You'd have to use "git create-lease" right > after you pull or push. But at the time I pull I don't know yet whether > I will later want to rewrite the branch, so to be sure I have to do this > every time I pull or push, and then I'd prefer git to do it for me. >
No, you don't set the sha1 as the tip of "origin/master" you set it as the tip of "master" after you've performed all the integration and are about to rewind history somehow. >> 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. > > I'm not sure I understand what you mean by "checking that your rewind-y > stuff is correct for the new origin/master"; does that mean manually > inspecting origin/master to convince youself that you are not > overwriting something new? If so, I don't think this is acceptable. It > is probably ok to work this way if the other party only pushed commits > on top; it's reasonable to expect that you will recognize new commits as > ones that you haven't seen before. But what if the other party has > rewritten the branch and squashed improvements into commits in the > middle of it? The head commit will then look the same as before, and the > only way to tell whether you are overwriting something new is by > comparing the old and new hashes. So then we're back at having to > remember what the old hash was. > You can do a diff rather than a check of the log. Thanks, Jake > > -- > Stefan Haller > Berlin, Germany > http://www.haller-berlin.de/
