[PATCH 5 of 6] lfs: infer the blob store URL from an explicit push source or default-push

Matt Harbison mharbison72 at gmail.com
Tue Apr 10 11:24:13 EDT 2018


> On Apr 10, 2018, at 9:34 AM, Yuya Nishihara <yuya at tcha.org> wrote:
> 
>> On Mon, 9 Apr 2018 17:43:47 -0400, Matt Harbison wrote:
>> 
>>>> On Apr 9, 2018, at 9:43 AM, Yuya Nishihara <yuya at tcha.org> wrote:
>>>> 
>>>> On Mon, 09 Apr 2018 00:26:45 -0400, Matt Harbison wrote:
>>>> # HG changeset patch
>>>> # User Matt Harbison <matt_harbison at yahoo.com>
>>>> # Date 1523211732 14400
>>>> #      Sun Apr 08 14:22:12 2018 -0400
>>>> # Node ID b8c871c097d3153d1eb71e0072cb7edf3356360c
>>>> # Parent  2aecf5b7dfdaeb12a6f6ac151d40c3b60f789abc
>>>> lfs: infer the blob store URL from an explicit push source or default-push
>>>> 
>> That works for exchange.push(), where the files are sent in a prepush hook.  That doesn’t work for pull -u, where the update occurs after the exchange.  Commands.postincoming() doesn’t have path info (that’s where repo._subtoppath comes in), and we can’t wrap commands.pull(), because that won’t help subrepos.
>> 
>> What about a hybrid approach of wrapping push(), but still looking at _subtoppath to handle pull?  That way, the core doesn’t have to change.
> 
> Ok, abusing _subtoppath would be no worse than the current state since the
> situation is quite similar to subrepo pull. So maybe it's okay for now.
> 
> Can you try to fix the mess after the 4.6 release? For "pull -u" of
> subrepos/lfs, we'll probably need
> 
> a) an API to explicitly prefetch changes (recursively?) from the specified
>    peer repository

Probably this one, for pull anyway. The current state of things is if you `hg pull -u <path>`, it does a parent checkout, and then tries to pull the subrepo.  If that fails, you’re left in the intermediate state that’s hard to recover from, especially if you had uncommitted changes.

It’s been on my list for awhile, but I’ll try to give it priority.

> b) or, a mechanism to carry peer path/repository while updating (something
>    like pull/pushop)
> c) or, a formal API to temporarily bind peer path/repository to the local
>    repo (i.e. formalize _subtoppath in some way)


More information about the Mercurial-devel mailing list