list mirror (unofficial, one of many)
 help / color / Atom feed
From: Dominik Salvet <>
Subject: Fetch origin/HEAD during git fetch
Date: Wed, 9 Oct 2019 03:37:27 +0200
Message-ID: <> (raw)

Hello Git community!
Imagine a repository initialised using git init. Then, a remote (e.g.,
origin) is added. Now, I want to fetch all branches, tags and commits
from the prepared remote to fill the local repository up for the first
time and do it as quick as possible. I want the origin/HEAD reference
to be fetched as well, and this is where the problem is - I don't know
how to do it optimally.

To summarise it, I want the following:

* Prepare a repository as quick as possible
* No local branches in the repository
* No files in working tree after downloading
* Working tree must be available (for further checkouts)
* Keep the information about its default branch (origin/HEAD)
* Updates can be fetched using a git fetch (ideally a plain one)
* The repository will not be ever used for pushing (it does not have
to be disabled)

Three sub-optimal solutions I have considered:

1) `git fetch origin && git remote set-head origin -a`
2) `git fetch origin +refs/heads/*:refs/remotes/origin/*
3) instead of git init and remote, use directly `git clone --no-checkout`

The first solution is not suitable due its delay caused by remote
access (2 separate invocations). For smaller repositories, delays of
these individual commands are almost comparable. However, this
solution is semantically exactly what I want.

The problem with the second solution is that it will create
origin/HEAD as a commit hash, not as a symbolic reference to a branch
(e.g., master). When master branch gets updated, it may cause problems
with further update fetching using a plain git fetch. Also, this
solution doesn't look very familiar and stable.

The third solution has several problems. The first one is the created
default local branch. So delete it. However, to delete it, I need to
checkout another commit and that modifies working tree, which can
cause unnecessary delay (namely for bigger repositories) as it may
(and will in most cases) be checked out to another commit later. Then
I can finally remove the local branch (after getting its name,

If you wonder which applications I need such restrictions for - I am a
developer of GitPack, a very simple Git-based package manager, and I
would like to solve the mentioned problem to improve storing
downloaded repositories in GitPack cache. It would allow GitPack
projects to use a different default branch than master branch, which
is currently hard-coded in GitPack.

I hope everything is clear. If not, do not hesitate and ask me. I
would really appreciate your help.

Thank you for all your effort
Dominik Salvet

             reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09  1:37 Dominik Salvet [this message]
2019-10-09  2:24 ` Jonathan Nieder
2019-10-09 14:29   ` Dominik Salvet

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone