darcs

Issue 2742 repos made with clone --no-working-dir cannot be cloned remotely (incomplete pristine)

Title repos made with clone --no-working-dir cannot be cloned remotely (incomplete pristine)
Priority bug Status needs-diagnosis/design
Milestone Resolved in
Superseder Nosy List jmcarthur
Assigned To
Topics Hashed

Created on 2026-07-18.22:47:09 by jmcarthur, last changed 2026-07-18.22:47:09 by jmcarthur.

Messages
msg24213 (view) Author: jmcarthur Date: 2026-07-18.22:47:08
1. Summarise the issue (what were you doing, what went wrong?)

I set up repositories for serving by cloning locally on the server host
with --no-working-dir. Cloning the resulting repository from another
machine fails:

    Couldn't fetch 5891b5b52...
    in subdir pristine.hashed from sources:
    thisrepo:...
    cache:...
    repo:host:/abs/path/B
    Run `darcs repair` to fix this problem.

The advice can't be followed on the client, because it's the remote
repository in need of repair.

The cause, as far as I can tell: a local clone with --no-working-dir
does not copy the file-content objects into _darcs/pristine.hashed. They
stay reachable through the new repository's _darcs/prefs/sources entry,
which points at the source repository's local path. This is fine where
the repository sits, but a remote client does not use the served
repository's sources. The clone works if the client's cache already
happens to hold the missing objects, but fails otherwise.

Reproduction with 2.18.5:

    mkdir A && cd A && darcs init
    echo hello > f.txt
    darcs record -lam init -A 'T <t@t>'
    cd ..
    darcs clone --no-working-dir A B
    ls A/_darcs/pristine.hashed | wc -l    # 3
    ls B/_darcs/pristine.hashed | wc -l    # 2
    comm -23 <(ls A/_darcs/pristine.hashed | sort) <(ls B/_darcs/
pristine.hashed | sort)
    # 5891b5b52... = sha256 of "hello\n", the file content
    cat B/_darcs/prefs/sources
    # repo:/abs/path/to/A

A default clone and a --lazy clone both copy all 3 objects. Only
--no-working-dir leaves one out.

Overriding XDG_CACHE_HOME simulates having a fresh cache:

    export XDG_CACHE_HOME=$(mktemp -d)
    darcs clone --lazy host:/abs/path/B C
    # fails as quoted above, exit 2

`darcs check` in B prints "The repository is consistent!" and silently
writes the missing object into B's pristine, fixing the issue. `darcs
repair` does the same thing, printing "already consistent".

2. What behaviour were you expecting instead?

I expected the bare clone to be servable, since serving it is the point
of a bare repository. I also think `check` should not call a repository
consistent when it can't be served, and it surprised me a bit that
checking a repository would also modify it even while saying it's fine.

3. What darcs version are you using? (Try: darcs --exact-version)

darcs --version:        2.18.5 (release)
darcs --exact-version:  prints "Weak Hash: not available" and an empty
context (distro build)

4. What operating system are you running?

Arch Linux (x86_64)
History
Date User Action Args
2026-07-18 22:47:09jmcarthurcreate