Re: Tools that do an automatic fetch defeat "git push --force-with-lease"
- From
Jacob Keller <jacob.keller@gmail.com>
- Date
- Apr 9, 2017, 08:46 UTC
- Message-ID
- <CA+P7+xrxH2kDSt02TTYyiKB2PgQr33j=-=ewATmvp2mJKTMMAA@mail.gmail.com>
- In-Reply-To
- <1n47l28.1xcy707zz3evtM%lists@haller-berlin.de>
On Sun, Apr 9, 2017 at 1:38 AM, Stefan Haller <lists@haller-berlin.de> wrote:
Show 17 quoted lines
> Jacob Keller <jacob.keller@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.
Show 19 quoted lines
>> 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
Show 5 quoted lines
> > -- > Stefan Haller > Berlin, Germany > http://www.haller-berlin.de/