How to initialize git without the global directory? - laravel

I want to put my LARAVEL project from the git repository to my server, to do this I:
git init
sudo git clone git#gitlab.com:test-name/my-project.git
Now I have the following content:
drwxr-sr-x 4 ubuntu www-data 37 Mar 26 08:53 ./
drwxr-xr-x 6 root root 101 Sep 5 2019 ../
drwxr-sr-x 7 root www-data 119 Mar 26 08:53 .git/
drwxr-sr-x 12 root www-data 4096 Mar 26 08:53 my-project/
and now when I list my-project I also see .git\ directory !
But in fact I want the content of my-project directly, not inside my-project directory.
What should I do ?

Don't bother with the git init at all: git clone means:
Make a directory, and enter that directory, so that all of the remaining five steps occur in that directory.
Run git init.
Run git remote add origin url, where the url comes from the git clone argument. You can change this name from origin to some other name, but you didn't.
Run any necessary git config operations (you didn't list any extra configurations to apply so this step doesn't do anything in your case).
Run git fetch origin.
Run git checkout name, where the name comes from the -b argument you gave to git clone. You didn't give one, so instead, name comes from the recommendation that the other Git over at origin gives. Most other Gits recommend master.
Note that step 2 does its own git init, so that's why you should not be doing one yourself. (If you like, you can run all six steps yourself, one at a time. Note that if you do that, you'll wind up in the directory you made. When git clone makes the directory and enters it, that doesn't move you, so this is slightly different.)
(In general, you should not be running any Git command with sudo. You might have some particular reason for doing that, but in general you should find some way to avoid doing that.)

Related

Git Files not being pushed to remote repository [Windows]

So I'm just learning Git, and can't tell what I'm doing wrong in setting up a local and remote repo for my scripts. Originally, the remote repo was going to live on a fileshare (\server\share$\scripts), but I can't even seem to get this to work on my local machine.
I've done my research, and read up on some of the common pitfalls, but I still can't seem to get files accurately reflected in my remote repo when pushing from the local one.
What I have:
Local Repo: In C:\git, with one file "test.txt" created by:
cd C:\git
git init
echo "Hello World" > test.txt
git add .
git commit
Remote Repo: C:\test
git --bare init
Then, when I specify a remove branch with:
git remote add origin C:\test
git push origin master
It tells me all is fine:
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 315 bytes | 315.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To C:\test
06e076a..62b6130 master -> master
And further git pushes return "Everything up-to-date", but the files are never pushed to the remote repository. Querying the logfile indicates that the push did in fact take place:
commit 62b6130cedef529ef97aec5333fcbee96c5e9a2f (HEAD -> master)
Author: [Redacted]
Date: Wed Jan 24 15:21:37 2018 -0500
TEST COMMIT
So where are the files? I'm on the right branch (master), and I even ran a git config receive.denyCurrentBranch false because some other similar threads suggested this as a fix.
Looking for some guidance here, appreciate any and all help!
Your remote repository is a bare repository. This means there simply is no checked out working tree. Just the git objects and branches and tags.
Having a working tree (aka your files in the most up to date master branch) doesn't make any sense for a remote repository. This is where you store all versions of all your files in one place. How should git know which branch/version/commit to use in the working tree?
I also found this description: Source
git init is for working
git init --bare is for sharing
To get your files back again, you need to clone from there.
git clone C:\test .
This will create a new repository with working tree.
Here are some links:
What's the -practical- difference between a Bare and non-Bare repository?
http://bare-vs-nonbare.gitrecipes.de/

.git directory does not appear as a directory on Windows

I cannot cd into some of my .git directories on Windows.
Some of my repositories are fine. The .git directory appears as you would expect in them:
drwxrwx---+ 1 grandps Domain Users 0 Oct 11 15:42 .git
I can cd into the .git directory, and ls it to see its contents.
In other repos, the .git directory shows up as a regular file. I can't cd into it or ls to see its contents. If I try to open it in Windows Explorer, I can't - Windows thinks it's a file, too.
-rwxrwx---+ 1 grandps Domain Users 68 Jun 22 12:22 .git
The repo still works as a git repository. I can run git commands just fine. I just can't get into the .git folder.
I have tried both Git Bash (MinGW64) and Cygwin. Both give the same results.
Any ideas how this could have happened, and how I can fix it?
According to documentation, the file should contain path to the actual repository directory.
Also you can have a plain text file .git at the root of your working tree, containing gitdir: to point at the real directory that has the repository. This mechanism is often used for a working tree of a submodule checkout, to allow you in the containing superproject to git checkout a branch that does not have the submodule
source: https://git-scm.com/docs/gitrepository-layout

'git rev-parse --is-inside-work-tree' doesn't recognize working tree or subdirectories

After updating to the latest Windows Git (2.5.0 from 1.6.2) I find I'm unable to rebase a branch:
C:\core\guidewire\Dev\2.4>git checkout fhcf-assumptiondate && git rebase master
Previous HEAD position was d032e17... Merge branch 'de8041'
Switched to branch 'fhcf-assumptiondate'
First, rewinding head to replay your work on top of it...
fatal: C:\Program Files\Git\mingw64/libexec/git-core\git-am cannot be used without a working tree.
Comments on this question hint at a Git installation conflict, but the old version is entirely removed by now, including a lingering DLL and checking for stale environment vars.
Looking inside the git scripts, I find that the error message is coming from a test in git-sh-setup that uses git rev-parse --is-inside-work-tree. Consulting rev-parse directly shows that it seems to not understand that I really am inside the working copy:
C:\core\guidewire\Dev\2.4>dir .git
Volume in drive C is System (Local)
Volume Serial Number is D4EC-4ED4
Directory of C:\core\guidewire\Dev\2.4
08/04/2015 21:16 27 .git
1 File(s) 27 bytes
0 Dir(s) 155,451,965,440 bytes free
C:\core\guidewire\Dev\2.4>git rev-parse --is-inside-work-tree
false
...Except some commands are able to correctly tell the difference:
C:\core\guidewire\Dev\2.4>git status
HEAD detached from refs/heads/fhcf-assumptiondate
nothing to commit, working directory clean
C:\core\guidewire\Dev\2.4>cd ..
C:\core\guidewire\Dev>git status
fatal: Not a git repository (or any of the parent directories): .git
What is making Git confused about whether I'm in the right directory or not?
Possible points of interest:
Repo was created by the previous installation.
1.6.2 was an msys build of Git. 2.5.0 is MinGW.
The repo was cloned with --separate-git-dir.
checkout, status, add, commit and possibly others all have worked without issue since the upgrade.
A clone of the broken repository exhibits correct behavior; 'in' or 'out' of the working tree are detected correctly.
To continue using an existing (1.6.x-created) repository after upgrading to Windows Git 2.5, update the repo's gitconfig:
[core]
worktree = c:/core/guidewire/Dev/2.4
to
[core]
worktree = C:/core/guidewire/Dev/2.4
The new Git installation either obtains paths differently from the old, or is no longer case-insensitive about paths. Therefore the existing repo working tree location becomes wrong since no folder under c:\core\guidewire\Dev\2.4 will have a prefix of C:\core\guidewire\Dev\2.4. Git source for the current version shows no sign of case-insensitivity, so the msys fork may have modified the path-checking function, or case-smashed all paths prior to comparison.

How to backup octopress when I publish on Github

I launch my own octopress yesterday,
And our blog articles are stored under source folder/
however when I run rake deploy , it only push the public data to github server.
because the default .gitignore are as following
1
2 .bundle
3 .DS_Store
4 .sass-cache
5 .gist-cache
6 .pygments-cache
7 _deploy
8 public
9 sass.old
10 source.old
11 source/_stash
12 source/stylesheets/screen.css
13 vendor
14 node_modules
Is there any better way to put your source markdown file in the GitHub server, to avoid I delete the source code accidently.
Thanks
I don't see anything wrong with the gitignore file. Maybe your problem is with your git branch.
Try this $ git branch if it says master you have to rename the branch to source like this:
$ git branch -m master source
Then when you do $ git branch again it should say source
When you deploy you should git add, git commit then $git push origin source then rake deploy
Let me know if this works
rake deploy will push changes in _deploy folder to master branch.
After rake deploy, if you do git push origin source under ~/octopress folder then your posts will be pushed to the source branch of your repo.

"(.hg not found)" when cloning from cygwin-hosted repository via ssh to Mac and FreeBSD clients

I am running an archival filesystem on a Windows server that does automatic offsite replication which makes it the ideal place to host Mercurial repositories and be sure of their safety. This filesystem is Windows-only so I have no choice but to use Windows as the host OS.
Setup:
Server ('ungoliant', internal to my network):
Windows 7 master repository host machine.
Cygwin ssh daemon.
hg 1.9.3
Created new repository "/cygdrive/j/mercurial/rcstudio" on Windows with "hg init".
Clients:
Mac OSX 10.7.4 running hg 2.1.2
FreeBSD 8.3 running hg 2.1.2
Problem on Clients (identical on Mac and FreeBSD):
$ hg clone ssh://cjp#ungoliant//cygdrive/j/mercurial/rcstudio
running ssh cjp#ungoliant 'hg -R /cygdrive/j/mercurial/rcstudio serve --stdio'
remote: abort: There is no Mercurial repository here (.hg not found)!
abort: no suitable response from remote hg!
I've confirmed that the path and the URI are correct. There absolutely is an ".hg" directory there:
$ ls -la
total 0
drwxr-xr-x 3 cjp staff 102 Jun 5 17:41 .
drwxr-xr-x 41 cjp staff 1394 Jun 5 16:30 ..
$ scp -r cjp#ungoliant:/cygdrive/j/mercurial/rcstudio/.hg .
$ ls -la
total 0
drwxr-xr-x 3 cjp staff 102 Jun 5 17:41 .
drwxr-xr-x 41 cjp staff 1394 Jun 5 16:30 ..
drwxr-xr-x 5 cjp staff 170 Jun 5 17:41 .hg
$ ls -la .hg
total 16
drwxr-xr-x 5 cjp staff 170 Jun 5 17:41 .
drwxr-xr-x 3 cjp staff 102 Jun 5 17:41 ..
-rw-r--r-- 1 cjp staff 57 Jun 5 17:41 00changelog.i
-rw-r--r-- 1 cjp staff 33 Jun 5 17:41 requires
drwxr-xr-x 2 cjp staff 68 Jun 5 17:41 store
I've found plenty of stackoverflow questions where the issue was an improperly formatted ssh URI ... mine is formatted correctly and describes an absolute path.
I have confirmed all the following:
hg commands run fine both on the server and through ssh.
If I paste the absolute path I am able to confirm the existence of the .hg directory through ssh.
Other hg commands manually issued through ssh succeed (e.g.: ssh cjp#ungoliant 'cd /cygdrive/j/mercurial/rcstudio; hg diff;').
On the host machine I can clone locally from that same absolute path.
I'm stumped here. The Mercurial docs make it sound like 2.1.2 should be able to clone from 1.9.3 parents, so it doesn't appear to be a version conflict.
Would very much appreciate your help! Thanks!
What I have ended up with is a workaround and not an answer.
My own ignorance of remote ssh command processing lead to a misunderstanding. If I would ssh to the machine, "which hg" resulted with the cygwin-aware binary "/usr/bin/hg", but if I did a remote command "ssh cjp#ungoliant 'which hg'", it returned the path to a windows binary I also have installed on that machine.
I played with my .bashrc file and could not get remote command execution to prioritize the cygwin binary. The PATH doesn't even include the Windows PATH entries, so I started hacking around the problem and eventually decided to stop fighting with it.
I have since abandoned the entire idea because I'm convinced that even if I get it to work it will be a delicate kludge and not at all worth the time I've spent on it. I now host my repositories on a BSD box and I have a cron on the Windows machine that pulls from that repository onto the archival filesystem once every 24 hours. It's simple and worked like a charm with zero problems.
I had the same issue, solved it by adding the option --remotecmd like this
hg clone --remotecmd /usr/bin/hg ssh://me#mywindowspc//cygdrive/m/hgrepo
When you attempt an scp you would do the following:
scp username#ipaddr:/cygdrive/d/test/foo.txt ./myDestFolder
Unfortunately for hg that does not work. Instead try:
hg clone ssh://username#ipaddr/D:/testRepo

Resources