From: Jeff King <peff@peff.net>
To: Stefan Haller <haller@ableton.com>
Cc: "Jacob Keller" <jacob.keller@gmail.com>,
"Ævar Arnfjör? Bjarmason" <avarab@gmail.com>,
"Matt McCutchen" <matt@mattmccutchen.net>,
git <git@vger.kernel.org>, "Junio C Hamano" <gitster@pobox.com>
Subject: Re: Tools that do an automatic fetch defeat "git push --force-with-lease"
Date: Mon, 10 Apr 2017 14:31:20 -0400 [thread overview]
Message-ID: <20170410183120.oa5yqwvlrdzitqci@sigill.intra.peff.net> (raw)
In-Reply-To: <1n47m37.1xocjxu1j1pyM%haller@ableton.com>
On Sun, Apr 09, 2017 at 10:38:42AM +0200, Stefan Haller wrote:
> Jeff King <peff@peff.net> wrote:
>
> > > 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.
>
> I think it's wrong to think about these leases as something that you
> take before you start a rewindy operation. That's the wrong time to take
> the lease; by that time, the remote tracking branch may already contain
> new things that you haven't seen yet, so using that as a lease at that
> time will overwrite those things later. You have to take the lease at a
> time where you know that your local branch and the remote tracking
> branch are up to date with each other, which is after pull and push. And
> if you do that, there's no multiple-operation ambiguity to deal with at
> all.
OK. I was assuming that you'd have just integrated before starting such
a rebase, but I guess that doesn't have to be the case.
I agree that probably makes the multiple-operation stuff go away, which
is nice. It does raise the question of when the integration point
happens, and how we handle alternate paths through which commits may
land in a local branch (e.g., if both you and upstream do a ff-merge of
a particular branch). I think that would probably just end up with extra
failures though (so erring on the side of caution). As long as those
aren't too common (and this check would kick in only when you're doing
--force-with-lease in the first place, so presumably not often), I think
it'd be OK.
-Peff
next prev parent reply other threads:[~2017-04-10 18:31 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-08 2:15 Tools that do an automatic fetch defeat "git push --force-with-lease" Matt McCutchen
2017-04-08 7:24 ` Stefan Haller
2017-04-08 7:35 ` Ævar Arnfjörð Bjarmason
2017-04-08 9:29 ` Jeff King
2017-04-08 10:10 ` Jakub Narębski
2017-04-08 11:41 ` [PATCH] push: document & test --force-with-lease with multiple remotes Ævar Arnfjörð Bjarmason
2017-04-09 9:55 ` Simon Ruderich
2017-04-09 11:40 ` Ævar Arnfjörð Bjarmason
2017-04-17 3:56 ` Junio C Hamano
2017-04-19 9:22 ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2017-04-08 21:54 ` Tools that do an automatic fetch defeat "git push --force-with-lease" Jacob Keller
2017-04-08 22:13 ` Jeff King
2017-04-08 22:21 ` Jacob Keller
2017-04-09 8:38 ` Stefan Haller
2017-04-09 8:49 ` Jacob Keller
2017-04-09 11:00 ` Stefan Haller
2017-04-10 8:08 ` Jacob Keller
2017-04-10 9:58 ` Ævar Arnfjörð Bjarmason
2017-04-10 23:33 ` Jacob Keller
2017-04-11 8:51 ` Junio C Hamano
2017-04-12 9:11 ` Stefan Haller
2017-07-06 18:56 ` [PATCH] push: disable lazy --force-with-lease by default Junio C Hamano
2017-07-06 19:38 ` Stefan Beller
2017-07-06 22:39 ` Junio C Hamano
2017-07-06 22:42 ` Stefan Beller
2017-07-10 22:32 ` Stefan Beller
2017-07-07 9:24 ` Stefan Haller
2017-07-07 9:42 ` Jeff King
2017-07-07 9:54 ` Ævar Arnfjörð Bjarmason
2017-07-07 15:15 ` Junio C Hamano
2017-07-15 10:45 ` Ævar Arnfjörð Bjarmason
2017-07-17 17:28 ` Junio C Hamano
2017-07-07 9:39 ` Ævar Arnfjörð Bjarmason
2017-04-11 12:37 ` Tools that do an automatic fetch defeat "git push --force-with-lease" Stefan Haller
2017-04-11 12:37 ` Stefan Haller
2017-04-10 18:31 ` Jeff King [this message]
2017-04-11 12:37 ` Stefan Haller
2017-04-11 12:50 ` Jeff King
2017-04-12 9:11 ` Stefan Haller
2017-04-09 8:38 ` Stefan Haller
2017-04-09 8:46 ` Jacob Keller
2017-04-08 8:25 ` Jacob Keller
2017-04-08 9:31 ` Jeff King
2017-04-08 15:03 ` Stefan Haller
2017-04-08 22:03 ` Jeff King
2017-04-08 15:03 ` Stefan Haller
2017-04-08 16:04 ` Ævar Arnfjörð Bjarmason
2017-04-08 17:28 ` Stefan Haller
2017-04-12 9:11 ` Stefan Haller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170410183120.oa5yqwvlrdzitqci@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=haller@ableton.com \
--cc=jacob.keller@gmail.com \
--cc=matt@mattmccutchen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).