git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* Fetch origin/HEAD during git fetch
@ 2019-10-09  1:37 Dominik Salvet
  2019-10-09  2:24 ` Jonathan Nieder
  0 siblings, 1 reply; 3+ messages in thread
From: Dominik Salvet @ 2019-10-09  1:37 UTC (permalink / raw)
  To: git

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/*
HEAD:refs/remotes/origin/HEAD`
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,
though).

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-09  1:37 Fetch origin/HEAD during git fetch Dominik Salvet
2019-10-09  2:24 ` Jonathan Nieder
2019-10-09 14:29   ` Dominik Salvet

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	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:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git