How to convert a normal Git repository to a bare one?
Solution 1
In short: replace the contents of repo
with the contents of repo/.git
, then tell the repository that it is now a bare repository.
To do this, execute the following commands:
cd repo
mv .git ../repo.git # renaming just for clarity
cd ..
rm -fr repo
cd repo.git
git config --bool core.bare true
Note that this is different from doing a git clone --bare
to a new location (see below).
Solution 2
Your method looks like it would work; the file structure of a bare repository is just what is inside the .git directory. But I don't know if any of the files are actually changed, so if that fails, you can just do
git clone --bare /path/to/repo
You'll probably need to do it in a different directory to avoid a name conflict, and then you can just move it back to where you want. And you may need to change the config file to point to wherever your origin repo is.
Solution 3
I think the following link would be helpful
GitFaq: How do I make existing non-bare repository bare?
$ mv repo/.git repo.git
$ git --git-dir=repo.git config core.bare true
$ rm -rf repo
Solution 4
Unless you specifically want or need to twiddle bits on the filesystem, it really is dead simple to create a bare version of a non-bare repository (mentioned in several other posts here). It’s part of git’s core functionality:
git clone --bare existing_repo_path bare_repo_path
Solution 5
Please also consider to use
git clone --mirror path_to_source_repository path_to_bare_repository
From the documentation:
Set up a mirror of the source repository. This implies --bare. Compared to --bare, --mirror not only maps local branches of the source to local branches of the target, it maps all refs (including remote-tracking branches, notes etc.) and sets up a refspec configuration such that all these refs are overwritten by a git remote update in the target repository.
Boldewyn
Boldewyn is the name of the donkey in German fables (at least, the ones from Goethe). Despite its bad name, a donkey is an animal with its own head and quite a portion of wit. As someone pointed out once, if you say to a horse to jump down that abyss, it would happily do so, whereas the donkey would give you a kick where you deserve it to. And someone else pointed out, that laziness is a core requirement for a good developer...
Updated on July 11, 2022Comments
-
Boldewyn almost 2 years
How can I convert a 'normal' Git repository to a bare one?
The main difference seems to be:
in the normal Git repository, you have a
.git
folder inside the repository containing all relevant data and all other files making up your working copyin a bare Git repository, there is no working copy and the folder (let's call it
repo.git
) contains the actual repository data
-
Boldewyn over 14 yearsThanks for the hint at
core.bare
. Now, after googling this option, I can confirm it: kernel.org/pub/software/scm/git-core/docs/git-config.html -
nosatalian about 14 yearsWrong, this method is not the equivalent. Doing a clone doesn't preserve config options, which can be critical to proper operation such as if you use git-p4. Additionally, a clone destroys remotes, again with something like git-p4 you lose the p4/master branch when you clone, so the above approach is preferable.
-
Philipp about 14 yearsBut you can transfer config options easily by copying the respective parts of the config file. I'd still consider this method to be cleaner than copying and renaming files manually.
-
Boldewyn almost 14 yearsYes, that's quite what I searched, thanks! However, their second proposal (
git clone
) has the drawbacks that nosatalian mentioned above. -
Benbob over 13 yearsThis is perfect after a subversion migration since git-svn lacks support for --bare.
-
Toby about 12 yearsCan I go ahead and delete any branch/remote information left in the config file? I'd previously clones from another and am switching my local copy to be a remote 'master'... thanks
-
JasonWoof about 12 yearsThank you! This seems cleaner to me: mv repo/.git repo.git && rm -rf repo && cd repo.git && git config --bool core.bare true
-
Jürgen Paul about 12 yearswill the files still exist if I did this?
-
djd almost 12 yearsThis is so much more complicated and fragile than the answer below (
git clone --bare /path/to/repo
). -
Lie Ryan almost 12 yearsthis isn't really much safer since you made your backup using git clone. Backup by cloning will cause you to lose some configurations, which in certain cases might be critical for the repository.
-
raksja almost 12 yearsTo avoid the name conflict ---
git clone --bare /path/to/repo.git /path/to/newbarerepo.git
-
Antony Hatchkins almost 12 yearsThis will not make it bare enough. Try pushing into it. You need to do
git config core.bare true
as well. -
sdesciencelover almost 12 yearsNoted. The only configurations I've ever cared about are global to all my local repositories.
-
minopret almost 12 yearsThat
rm
command may need* \.[!.]*
rather than*
in order to remove dot-files and dot-directories. -
Ciantic over 11 yearsThis command assumes that directory
../
doesn't have.git
directory or file inside. If so, it may cause unexpected behavior. -
Jörg W Mittag over 11 years@Ciantic: Again, as I already explained in my comment above, my answer was given 3 years ago, but 5 months ago someone edited the question into something completely different. None of the answers on this page will make any sense anymore. That sequence of commands was directly copied from the question, I just added the last two lines.
-
user1338062 over 11 years.git/index can be removed too, bare repo does not need it.
-
Janikan over 11 yearsThe link that @Boldewyn points to confirming the core.bare section has moved to: kernel.org/pub/software/scm/git/docs/git-config.html
-
Stabledog almost 11 yearsWhat's the intermediate clone for?
-
Stabledog almost 11 yearsKind of amazing that the far-and-away best answer has 0 votes after > 4 months. The not-very-good-but-dangerous 'accepted answer' has 200!
-
Emily L. almost 11 yearsI find that this answer: stackoverflow.com/a/1784612/2498188 is much cleaner.
-
GreenAsJade over 10 yearsNot amazing at all - this answer does not do what the original question asked. It doesn't convert a repo, it clones one, losing information in the process (for example, remote branches).
-
ggll over 10 yearsI tried both this and the following clone option, and the result differs. Also the wiki recommends to use the clone approach, see git.wiki.kernel.org/index.php/…
-
Boldewyn about 10 yearsHave you bothered to read the other answers? Especially @jonescb's and @nosatalian's comment to it? The "git" method is this: "Do as much as possible with plain text files". You should start investigating the internals of a
.git
folder. It's highly educating to learn, how the parts fit together. -
Admin almost 10 yearsI didn't downvote, but I just wanted to point out that the 1st part of this answer that explains why you would want a bare repo vs a non-bare one is ok, though it doesn't contain enough technical detail, and may be slightly inaccurate. However, for the 2nd part of your answer, while those commands do set up your repo to be bare, Anthony is right, you still need to set
git config core.bare true
, just like in this answer. -
Bouncing Bit over 9 yearsIf you have SourceTree installed you simply can checkout the bare repository to a new folder by... Selecting "New Repository -> Clone from URL", Copy&Paste the path to the local folder into "Source URL", Clicking "Clone". This will create a new folder with the checked out bare repository.
-
ceztko about 9 yearsDidn't work for me. I had conflicts to resolve which does not make sense.
-
Manish Singh almost 9 years
cd repo ; cp -r .git ../repo.git
-
Boldewyn over 8 yearsI fail to see, what this answer adds, that hasn’t been discussed in arbitrary length in any of the other answers around (including the downvoted). Could you please clarify? (By the way: the Pro Git Book says “This is roughly equivalent to something like…”, and that exact rough equivalence is also already discussed here.)
-
Boldewyn over 8 yearsThis is dangerous, when you also want to work on the work tree of the remote repo. Chances are, that sooner or later you revert a change simply because your remote work tree and index weren't in sync with the repository. I do not recommend this solution, if you do not exactly know what you're doing.
-
Slion over 8 yearsTrue, you should not work on the tree of the remote bare repo.
-
dafunker almost 8 yearsThe documentation you suggested goes on to say, "A safer method is to let Git handle all the internal settings for you by doing something like this... git clone --bare -l <path_to_repos> <new_dir>"
-
gyorgyabraham over 7 yearsI must tell that gitlab thinks the repo is empty after this operation
-
ACK_stoverflow over 6 yearsThis works as long as you run
git update-server-info
on the bare repo after creation. -
Craig Silver over 6 yearsSeems like this is the most concise, complete and safe way to do what the OP wants (vs. just
clone
). Am I missing something? Was--mirror
a relatively recent addition? -
Jacek Krawczyk over 6 years@CraigSilver: No, as I see in the documentation history in such a form the
--mirror
is available from the version 1.7, so already pretty long. You can check out here -
Psychonaut almost 6 yearsThis answer does not work as written if the repository you want to convert happens to be a module of an existing repository. In this case
.git
is not a directory but a file that contains the path to the actual.git
directory you must move. -
Keith Russell over 3 yearsDo we have to do this afterward?
-
AaA over 3 yearsI think log folder need to be deleted too. Also to those 61 people who think
git clone
is a better solution, try doing it 397 times (re-constructing a vanished server) -
0xC0000022L about 3 yearsOf course it begs the question why Git is lossy in the first place (and yeah, I know of
git clone --mirror
) but to the best of my knowledge the meaning of clone in English isn't "duplicate except for these random unspecified parts" 😉 ... of course the meaning of Git subcommands isn't always exactly self-explanatory, so I guess I'm doing Git wrong by expecting English subcommands to follow the English meaning of the words. -
stackprotector about 3 yearsAfter reading this answer, some people might want to read this question: stackoverflow.com/q/3959924/11942268
-
Boldewyn over 2 yearsThis is something completely different and in no way related to bare or non-bare repositories. Orphan branches are simply branches, that do not share a history with other branches. Therefore, if you create one, Git will show you a now empty work tree.
-
Martian2020 over 2 years@Boldewyn, yes, the output of
git status
would show different output, but the question said "bare...there is no working copy". runningswitch --orphan
produces that result. And when I found that QA I was looking for way to remove working copy files w/out breaking consistency of repository, so for my purpose I consider--orphan
as best, it does not result in drawbacks mentioned in comments to many top answers (e.g. config lost ifclone
is used). What problems could it introduce? -
Boldewyn over 2 yearsWell, to give you a somewhat close analogy. If my question was, “How do I create an empty folder?” your answer would’ve been “Look! If you run
rm -fr *
your current folder will be empty! What problems could it introduce?”. Bare repositories behave differently, especially when pushed to. Your repo is still non-bare. Git will, e.g., still complain that it can’t update the working copy of the repository when pushed to. Don’t get me wrong, orphan branches are a wonderful tool. Just for a completely different problem. -
Boldewyn over 2 yearsA quick explanation of bare repos: saintsjd.com/2011/01/what-is-a-bare-git-repository . Use case for orphan branches: shannoncrabill.com/blog/git-orphan-branches
-
Martian2020 over 2 years@Boldewyn, thank you. Would running after
--orphan
git config --bool core.bare true
convert to bare with all proper behavior? -
Boldewyn over 2 yearsYes, but the
switch --orphan
would still be unnecessary. You’d simply have an extra branch without commit laying around in the.git
folder. And theswitch --orphan
wouldn’t touch any git-ignored files anyway, so you cannot be sure, that it properly erased all the content of the old worktree folder. Sounds like extra work with additional disadvantages to me. -
Martian2020 over 2 years@Boldewyn, running only
git config --bool core.bare true
on a full working folder does not remove working files, just checked. And nobody here suggested that as an answer. -
Martian2020 over 2 years@Boldewyn, and w/out
--orphan
git switch empty1
outputsfatal: invalid reference: empty1
. git ignored can be deleted manually, I think I'll add that to the answer for completeness. -
Martian2020 over 2 years@Boldewyn, thank you for your comments! I've expanded my answer, as I want to use it myself it is already appreciated!
-
Raúl Salinas-Monteagudo over 2 yearsThis doesn't look like a oneliner candidate to me. I understand the negative votes.
-
zrfrank over 2 yearsDo notice that the original
config
is lost during the process. For example, "the remote", the remote of the new repo created by eithergit clone --bare A B
orgit clone --mirror A B
. If repoA
is cloned from say github, then A has remote url of[email protected]:*/*.git
. The repoB
would haveremote.origin.url=PATH_TO_A
.