Unable to create a bare git repository - linux

My git version is 1.5.0.6.
I want to create a bare git repository called sample.git.
I tried all sorts, but it failed:
Try 1:
Gives a usage statement but no git created
git init --bare sample.git
usage: git-init [--template=<template-directory>] [--shared]
Try 2: (using git-init not git init)
$ git-init --bare sample.git
usage: git-init [--template=<template-directory>] [--shared]
Try 3: Create a directory sample and then run same command, but still same output and git repository not created.
Please help me.

Firstly, upgrade your git. Version 1.5 is positively ancient.
If you can't upgrade, I'd just create a normal git repository, then manually convert it to a bare repo. An ordinary git repo will contain a '.git' directory. This can be your "bare" repo. Rename this directory to whatever you like. (You'll probably want to mv .git ../myrepo.git).
Then you have to tell git that it is a bare repo. Do this by adding bare = true to the config file in the [core] configuration section.

Related

pushing and pulling from remote git repo works but it is empty on remote server [duplicate]

This question already has answers here:
What's the -practical- difference between a Bare and non-Bare repository?
(11 answers)
Closed 2 years ago.
I have a linux server with ssh and git installed.
I created a folder on the root directory and changed its owner to mike to avoid giving out root passwords to anyone.
sudo mkdir /GitRepos
sudo chown mike:mike /GitRepos
Then I created an empty repo, and set it to bare, otherwise pushing to this repo does not work (I tried!!)
mkdir test.git
cd test.git
git init
git config core.bare true
I then used another machine (Windows) to clone the newly created repo:
git clone ssh://mike#myLinuxServer/GitRepos/test.git
and that worked fine, I got an empty repo as expected.
I added some files and committed the change.
git add .
git commit -m "Initial commit"
git push origin master
Pushing works fine. I even deleted the entire repo from the local machine, and tried to clone it again.
cd ..
rd test /s
git clone ssh://mike#myLinuxServer/GitRepos/test.git
It worked fine and I got all of the files.
When I went to the remote Linux machine, I listed the files inside test.git and found it empty.
Where did the files go?
How can the repo receive pushes and give out files for pulls without storing the files in the repo?
The files are stored in the remote repository's database. You cannot expect that the files themselves appear in the remote repository, in particular not when you declare it as bare.
The way you initialized the bare remote repository is very unusual. You should have done it simply like this:
cd /GitRepos
git init --bare test.git
The repository on the server is considered as a bare repo as you ran git config core.bare true. A more common way to initialize a bare repo is git init --bare test.git or mkdir test.git;cd test.git;git init --bare. The difference between git init test.git;cd test.git;git config core.bare true and git init --bare test.git lies in the directory structure. The former creates the worktree(test.git) and the database(test.git/.git) but forbids the worktree then. The latter creates only the database(test.git), without the worktree from the beginning.
A bare repository does not have an active worktree by default, which means you can't check out files from any revision in a bare repository. Although you can create extra worktrees with git worktree add, it's quite rare and may behave not so well as a non-bare repository with extra worktrees. All the revisions are stored as compressed data in the database. You can use commands to read the data, like git show master or git ls-tree -r master.
otherwise pushing to this repo does not work (I tried!!)
It's partially true. You can't push to a non-bare repository when you try to update a branch which has been checked out in the remote repository. If the branch you try to update is not checked out or does not exist yet, you can push to update or create it. With git config receive.denyCurrentBranch ignore or git config receive.denyCurrentBranch warn, you can even update such branch. But in practice, we always use bare repositories to preserve revision data.

git LFS tracked files are still big after git clone

I use git LFS in my repo, but the files (tracked by git LFS) still have size.
I follow this link and do these steps:
On gitlab/bitbucket
create a new repo on gitlab(also tested on Bitbucket)
On local
clone the repo on local PC
check git LFS is installed : git lfs install
create a big file head -c 2M /dev/urandom > one.model
start to large file git lfs track "*.model"
.gitattribute is ready
git add .
git commit -m "use lfs and upload one.model "
git push -u origin master
On gitlab/bitbucket
one.model has label "LFS" on gitlab(Bitbucket website)
On local
git clone the repo to another dir. Then go to repo-dir
ls -al to check size, file's size is still big.
I also test it on gitlab/bitbucket, but get the same result
Do I miss any instruction or settings?
Need your suggestions, thanks
Have you configured the GIT_LFS_SKIP_SMUDGE? You can do this by setting this in you environment directly:
GIT_LFS_SKIP_SMUDGE=1 git clone YOUR-REMOTE-REPO
or by setting it in config:
git config --global filter.lfs.smudge "git-lfs smudge --skip"
git clone YOUR-REMOTE-REPO
I hope this helps!
Are you using the versions suggested by the tutorial? and have you properly installed git-lfs?
Maybe re-do the tutorial and try again?

Cannot clone git repo inside existing checked out git repository

I am trying to clone my a git repository inside an existing checked out git repository and getting this failure. I've done this workflow before so I cannot figure out why it would fail now. Does anyone have any suggestions?
The git repository does exist and I can clone outside of the checked out repository in a different location
Let's say I do the following
1. cd <existing git repo clone folder>
2. git clone https://github.com/apache/cassandra
Cloning Git Repository of cassandra
Cloning into 'cassandra'...
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.
What could be causing this error?
PLEASE NOTE - I DO NOT WANT TO ADD THIS REPOSITORY AS A SUBMODULE TO MY PARENT GIT REPO. I simply want to figure out how to clone the repository in an existing working folder checked out from git.
Have a look at git submodules This was designed exactly for this. You can find information and examples here: https://git-scm.com/book/en/v2/Git-Tools-Submodules
In your case, this might work:
git submodule add https://github.com/apache/cassandra
In order to change the submodule to track a particular commit change directory to the submodule folder and switch branches as normal.
cd submodule
git checkout -b some_branch origin/some_branch
or for some particular tag
git checkout <version_tag>
You will need to commit this change to update.
Your question sort of seems to be in conflict. You can't have a git repo within another git repo without using git submodules AFAIK.
What you could do is have a dir that is not a git repo, and clone both the repos into that dir (so don't put the repos inside each other).
You could also add the repository as a remote (using git remote add name_of_remote http://your/remote/here). Then you can checkout any branch from either repo in the same repository.
I usually do not like to use submodules. for this case I would do the following:
1) in the main repo .gitignore the folder path where you want to store the repo the path-of-cassandra-repo/* (to ignore it)
2) in the terminal execute git clone https://github.com/apache/cassandra.git path-of-cassandra-repo/ where "path-of-cassandra-repo/" the name of the folder you want git to store the repo.
3) you are ready to go... Happy coding.
Let me know if this works for you...

How can I verify git clone is working correctly?

I'm following the documentation provided here by git to setup a bare git repository in a folder called root.
I started in the root directory where I ran
git init
git -A *
git commit -m "test"
I then ran git status and all appears good.
Next I ran the line from the documentation at a directory one level above the repo I created above.
git clone --bare root root.git
This created root.git but I cannot see any evidence that anything was cloned I just see a set of files and directories when I cd root.git.
I don't know how to verify it was actually cloned, and if it was why can't I see the original files?
When you do --bare --- you are telling git to clone just the git portion -
This is the option you use when you want to have a remote repository that does not include a workspace.
If you want to verify that it actually cloned your changes, you'll want to clone it again in a different directory - without the --bare flag
I would recommend using the full path to do this:
cd /path/to/some/workspace
git clone /path/to/your/root.git successful-git-clone #that last bit is optional
This will put the workspace contents of root.git into a folder named successful-git-clone/ - without that last bit, it will default to root/ -
Even if you are in a bare repository, some git commands works and you could do a git branch to see if you have all your branches or git log to look at your commits...

What is wrong with my git 1.8.4.2-1?

I have an old Synology DS-106j server where I tried to install git using ipkg command. The installation went smoothly, but git failed to work correctly. I am currently learning how to use git, so I don't know if it is a bug from git with the version I am using or something else is wrong.
What I did was create a new local repository with a specified name, add a new file, commit it, and got an error:
NAS_SERVER> git init Test
Initialized empty Git repository in /root/Test/.git/
NAS_SERVER> ls
Packages.gz git_1.8.4.2-1_powerpc.ipk
Test
NAS_SERVER> cd Test
NAS_SERVER> git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)
NAS_SERVER> touch Test.cs
NAS_SERVER> ls
Test.cs
NAS_SERVER> git add *
NAS_SERVER> git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: Test.cs
#
NAS_SERVER> git commit -m "Test"
fatal: 57e2b8c52efba71d84c56bf6f37581686b9061a3 is not a valid object
I thought...maybe I did something wrong, so I used git on Windows OS and try a push. Still an error. Transfer the whole repository to the server and check the status. It seems fine. Try a commit. Still the same result. What worse is that I can't update git version without having to compile it, which I don't even know how to do so. Any suggestion to what might be wrong?
If your goal is to push into a git repo located on the synology disk(s) for backup purposes I'd recommend a different approach which would avoid having to install a rather old git version on the synology box itself (which could lead to problems if/when using a newer git version on the windows machine).
Export a samba share from synology, mount it on windows and use the windows git to create the backup repo (maybe even a bare repo, eventually group shared if you plan to share work with other people). Then push from your working repo into this backup repo - all on the windows box. In this scenario the synology box doesn't need git installed, it just serves files (i.e. its original job).
I'm using such setup but with a linux machine instead of a windows one and with the bare repo on the synology disks exported via NFS instead of Samba.

Resources