On Mon, Jul 29, 2019 at 02:44:00PM -0700, Junio C Hamano wrote:
> > Hmm, true. I'd almost argue that --force-with-lease, at least in its
> > default mode with no explicit lease source specified, should allow an
> > update from X to Y to be a successful noop if the remote "somehow"
> > already move
Jeff King writes:
> Yeah, the auto-update of the tracking refs came later (so I think you
> could argue the bad interaction is my fault!).
Heh, I somehow thought it was somebody else.
> Hmm, true. I'd almost argue that --force-with-lease, at least in its
> default mode with no explicit lease so
On Mon, Jul 29, 2019 at 06:33:32AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > My general feeling is that having multiple push URLs for a remote is a
> > poorly designed feature in Git (and I think the discussion elsewhere in
> > this thread went there, as well).
>
> That's being gen
On Mon, 29 Jul 2019 06:33:32 -0700
Junio C Hamano wrote:
> I agree but only if the listed ones are separate ones. If the URLs
> are separate paths to reach the same remote (e.g. https:// and ssh://
> going to the same place), the current definition would make more
> sense.
I realize I’m a bit b
Jeff King writes:
> My general feeling is that having multiple push URLs for a remote is a
> poorly designed feature in Git (and I think the discussion elsewhere in
> this thread went there, as well).
That's being generous. I do not think it was even designed---at
least, the interaction with re
On Sat, Jul 27, 2019 at 09:54:40AM -0700, Christopher Head wrote:
> For each URL:
> 1. Read refs/heads/mybranch (call this commit X)
> 2. Read refs/remotes/myremote/mybranch (call this commit Y)
> 3. Send to the URL an atomic compare-and-swap, replacing Y with X.
> 4. If step 3 succeeded, change r
Christopher Head writes:
> On July 27, 2019 1:57:18 PM PDT, Junio C Hamano wrote:
> ...
>>In the reverse direction, I think "git fetch" supports the notion of
>> of repositories, so that fetch from multiple remotes can be
>>initiated with a single command, but I am not sure if we added the
>>sam
On July 27, 2019 1:57:18 PM PDT, Junio C Hamano wrote:
>What I would call "logically the same" is the set of repositories
>that are synchronized at the server side, which may or may not have
>multiple URLs to reach it, but behave as if it is just a single one
>without your doing anything special.
Christopher Head writes:
> On July 27, 2019 10:46:43 AM PDT, Junio C Hamano wrote:
>>Christopher Head writes:
>>
>>Quite honestly, the true culprit of the above story is that you are
>>letting multiple logically different remote repositories [*1*] use
>>the same single remote-tracking refes/rem
On July 27, 2019 10:46:43 AM PDT, Junio C Hamano wrote:
>Christopher Head writes:
>
>Quite honestly, the true culprit of the above story is that you are
>letting multiple logically different remote repositories [*1*] use
>the same single remote-tracking refes/remotes/myremote/ hierarchy.
They we
Christopher Head writes:
> Hi folks,
> When a single remote has multiple push URLs, Git’s force-with-lease
> logic appears to be:
>
> For each URL:
> 1. Read refs/heads/mybranch (call this commit X)
> 2. Read refs/remotes/myremote/mybranch (call this commit Y)
> 3
> from Y to X, and therefore
Hi folks,
When a single remote has multiple push URLs, Git’s force-with-lease
logic appears to be:
For each URL:
1. Read refs/heads/mybranch (call this commit X)
2. Read refs/remotes/myremote/mybranch (call this commit Y)
3. Send to the URL an atomic compare-and-swap, replacing Y with X.
4. If ste
12 matches
Mail list logo
