[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] git "pull" from bundle to bare repository

From: Greg Chicares
Subject: [lmi] git "pull" from bundle to bare repository
Date: Wed, 29 Apr 2020 15:03:28 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

Vadim--How can I "pull" a bundle to a bare repository? I can
"fetch", but that doesn't update HEAD, so when I later clone
from it, I get a stale-dated checkout.

Background: We have a git repository of proprietary product
data, which has no central server--we email bundles back and
forth to keep our work synchronized, and that works great.
On my own machine, I work with a nonbare copy in a chroot, and
occasionally push to a bare repository, still on my machine:
Months ago, we archived, emailed, and extracted that whole
bare repository onto our linux server, which I would now
like to update, so I prepared a bundle including everything
from the server's last update (07f31c96) to my current HEAD:

git bundle create catchup.bundle 07f31c96..HEAD --branches

and transmitted that to the server, on which I did this:

/srv/cache_for_lmi/blessed/proprietary[0]$git rev-parse HEAD
/srv/cache_for_lmi/blessed/proprietary[0]$git bundle verify ../catchup.bundle
The bundle contains these 2 refs:
b12435394717dcd45f37eead944ca82ab2a59812 HEAD
b12435394717dcd45f37eead944ca82ab2a59812 refs/heads/master
The bundle requires this ref:
./catchup.bundle is okay

So far so good. However:

/srv/cache_for_lmi/blessed/proprietary[0]$git pull ../catchup.bundle
fatal: /usr/libexec/git-core/git-pull cannot be used without a working tree.

/srv/cache_for_lmi/blessed/proprietary[1]$git fetch ../catchup.bundle
Receiving objects: 100% (1172/1172), 642.44 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1126/1126), completed with 115 local objects.
>From ../catchup.bundle
* branch            HEAD       -> FETCH_HEAD
/srv/cache_for_lmi/blessed/proprietary[0]$git rev-parse HEAD
/srv/cache_for_lmi/blessed/proprietary[0]$cat FETCH_HEAD
b12435394717dcd45f37eead944ca82ab2a59812                branch 'master' of 

I think I need that bare repository's HEAD to be updated, so that
when 'lmi_setup_43.sh' clones it in a debian-within-redhat chroot,
we get an up-to-date checkout:

--'lmi_setup_43.sh' snippet begins--
# First, copy "blessed" repository (here, 'cp' is sufficient: this
# bare repository has no references that need to be resolved):
cd /opt/lmi || { printf 'failed: cd\n'; exit 3; }
cp --dereference --preserve --recursive /cache_for_lmi/blessed .
# Then create a working copy by cloning the bare repository...
git clone -b master file:///opt/lmi/blessed/proprietary
# ...and verify it:
cd proprietary || { printf 'failed: cd\n'; exit 3; }
git rev-parse HEAD
--'lmi_setup_43.sh' snippet ends--

To confirm, I entered a chroot on the server and simulated that:

/tmp[0]$mkdir eraseme
/tmp[0]$cd eraseme
/tmp/eraseme[0]$git clone -b master file:///cache_for_lmi/blessed/proprietary
Cloning into 'proprietary'...
remote: Enumerating objects: 22462, done.
remote: Counting objects: 100% (22462/22462), done.
remote: Compressing objects: 100% (7438/7438), done.
remote: Total 22462 (delta 20484), reused 16639 (delta 15020), pack-reused 0
Receiving objects: 100% (22462/22462), 8.66 MiB | 8.81 MiB/s, done.
Resolving deltas: 100% (20484/20484), done.
/tmp/eraseme[0]$cd proprietary/
/tmp/eraseme/proprietary[0]$git rev-parse HEAD

I suppose I could copy the bundle into the chroot (where I'm
cloning the cached repository) and pull it there, but I really
don't want to, because the chroot is created automatically by
a suite of scripts, which don't look for bundles. It'd be much
cleaner to keep the cache (outside of any chroot) updated, and
I figure there must be some obvious answer to this question.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]