2

I'm trying to learn to use Git, and I kind of get the basics of pulling and pushing etc, but I'm confused on deletions.

This is what I've done (with fortrabbit and laravel):

  • Created a Laravel Project
  • run git init . in the project folder
  • run git remote add origin ...
  • run git add -A
  • run git commit -am 'Initial'
  • run git push -u origin master

Now my local copy matches my remote copy.

I now want to delete a file, so I create a test file:

  • run touch testfile1.php

I add the file, commit it then push it. Now I have the test file locally and remotely.

The problem is deleting it. This question is in 2 parts:

Reading this SO question: How can I delete a file from git repo? it says I should do:

  • git rm testfile1.php
  • git commit -m 'deleted file'
  • git push origin master

However that only deletes the local copy. The remote copy is still there!

If I delete it from my local copy, how does it get deleted from the remote version too?

My second question is, if someone else has a copy, how do they know I've deleted the file? If they push their copy back to the remote one, won't it just re-add the deleted file?

Any help is appreciated.

EDIT

This is the output of the git rm command, and the remote version after the command:

enter image description here enter image description here

The first image is me typing the git rm testfile1.php file. It then outputs rm testfile1.php and returns to the prompt. When I SSH back into the remote version, the testfile`.php is still there :/

Another Edit

I've just been reading some help articles provided by Fortrabbit, primarily, this one: http://help.fortrabbit.com/git#toc-behind-the-scenes

It says the it overwrites, but doesn't delete.

Would this be the reason why git says it's up to date, but the file is still in the web root? If so, for what reason could there possibly be not to delete a file that I've asked to be deleted?!

Community
  • 1
  • 1
Phil Cross
  • 9,017
  • 12
  • 50
  • 84
  • 1
    The file should be deleted on the remote as soon as you `git push origin master`. Can you add the output of the `git push` command to your question? You might need to `pull` first, then `push`. – Greg Burghardt Jul 29 '15 at 14:23
  • 2
    "However that only deletes the local copy. The remote copy is still there!" Pretty sure that's false. The steps above will delete both the local and remote copy. Just be sure you're running **`git`** `rm`, not just `rm`. – Ajedi32 Jul 29 '15 at 14:23
  • 2
    For your second question, next time they pull, git will delete the file from their working directory, so it won't get magically re-added. – Roman Jul 29 '15 at 14:26
  • I also think that there was an error output during `git push origin master`. Please post the console output. – Martin C. Jul 29 '15 at 14:27
  • Thanks for your comments so far, I've added 2 screenshots of the output of the command. – Phil Cross Jul 29 '15 at 14:32
  • @R0MANARMY thank you for the clear explanation :) Just one quick sub-question, what if they don't pull before merging? would they get a warning to re-fetch or something? – Phil Cross Jul 29 '15 at 14:33

6 Answers6

2

Ah okay, now I see the problem. You were expecting git push to change files in the working directory of the git repository on the server. That's not how it works. Pushing to a remote repo only updates the git object database, not the working directory. If you ran a git log on the server, you would see that the commit you pushed is, in fact, there, but the working directory hasn't been updated. A git reset --hard on the server should fix that.

Normally, git repositories on a server are created as something called a "bare repository". Bare repositories don't have a working directory, they just contain the underlying git object database. In your case though, you created a full (non-bare) repo on the server and used that as your remote. This is not recommended, as it creates problems similar to what you discovered here.

What you should do is create a bare repository on the server, then have your local checkout on the server clone and pull changes from that.

Ajedi32
  • 45,670
  • 22
  • 127
  • 172
  • You can't create a git repository on the server, it is à Paas – edi9999 Jul 29 '15 at 17:45
  • @edi9999 Huh? Yes you can. In fact, the use of a git repository on a server is a pretty common workflow from what I've seen. Even GitHub repositories are technically just git repositories on a server. – Ajedi32 Jul 29 '15 at 18:47
  • Ok, maybe you can, but the platform gives you the full benefits if you use their git repository (scaling, ...). See my answer. – edi9999 Jul 29 '15 at 18:51
  • @edi9999 Ah, makes sense. I'm unfamiliar with Fortrabbit, so my answer was more targeted towards git in general. – Ajedi32 Jul 29 '15 at 18:56
  • Thanks for the explanation on Git in general, since I know little about git, it's great to get all the information I can :) – Phil Cross Jul 29 '15 at 20:13
1

you didn't finish all the commands proposed by your tutorial:

git rm testfile1.php
git commit -m 'deleted file'
git push origin master

you only did the first one, you need to commit and push to the remote to delete the file there.

important remark: normally when you push to a remote, you push to a bare repository, it should NOT contain the files...

Here is a step by step process:

  1. local and remote are the same

git rm testfile1.php

  1. locally testfile1.php is removed, but this change isn't committed. testfile1.php is still present on remote.

git commit -m 'deleted file'

  1. locally testfile1.php is removed, this change is committed. Your local branch is 1 commit ahead of remote. (testfile1.php is still present on remote)

git push origin master

  1. local an remote are the same (if you are on a bare repository on the remote. otherwise, see @Ajedi32's answer.)
Chris Maes
  • 35,025
  • 12
  • 111
  • 136
  • I followed it up to step 3, and after a `git status` it did say that my local branch is 1 commit ahead. When I ran the `git push origin master` it ran the push. When I checked the remote server, the `testfile1.php` file is still there :( When I exit and run the `git push origin master` command again, it says everything is up to date! I'm deeply confused! – Phil Cross Jul 29 '15 at 14:46
1

This question is in fact specific to Fortrabbit : http://help.fortrabbit.com/git#toc-overwrite-but-not-delete

Overwrite but not delete

The old files will be overwritten with the ones that have been updated thru Git. However, Git deployment will not delete anything. So when you delete a file from your Git repo it will be still there in the webspace.

This is the safe default to deal with "runtime contents". When you implement something like an image upload form, you will upload additional contents to your webspace. Those files are generated on the webspace directly. So they are not part of Git repo. But most likely you don't want these to be deleted whenever you push code changes.

You can configure that behaviour with the fortrabbit.yml file:

http://help.fortrabbit.com/deployment-file

The contents of the file should be :

version: 1 
strategy: fullsync
excludes:
     - app/storage/ 
     - uploads/
     - vendor/

The fullsync means that the content of your webserver will be exactly the one as your local repository. The excludes key specifies which folders you would not autosync (you should put there all folders that could contain user data, like avatars, or things that are not in git but are required by your application like the vendor folder)

Community
  • 1
  • 1
edi9999
  • 19,701
  • 13
  • 88
  • 127
  • Kind of off-topic, but this seems like a pretty strange way to deal with "runtime contents" to me. git doesn't delete untracked files when it pulls anyway. Only tracked files that you explicitly deleted in the new revision are removed. I guess they're not actually using `git` for deploying the changes? – Ajedi32 Jul 29 '15 at 18:57
  • it does seem a weird way to deal with it! Unfortunately I don't know enough to know any better! I've tried the deployment file, deleted the file as normal and it was deleted from the remote server as well. Thank you for your answer, I guess it must be specific to FortRabbit! – Phil Cross Jul 29 '15 at 20:11
  • I think they use rsync for deploying between the git server and the different nodes that make your application – edi9999 Jul 29 '15 at 20:14
  • Make sense. Since git isn't actually involved in deploying those files, they had to come up with their own mechanism for making sure untracked files didn't get clobbered. – Ajedi32 Jul 29 '15 at 20:29
0

Delete the file locally

 rm testfile1.php

Then run,

 git rm testfile1.php
 git commit -m 'deleted file'
 git push origin master

(This is how I do it in my daily life.)

If you delete the file and successfully push your changes, then, other person will not be able to push his/her changes until they pull the changes. During that process, the file will get deleted from thier clone of the repo. Occassionally, they may get conflict if they have changes committed locally to same file, indicating that the file is deleted on remote and changed on local. They can resolve conflict and then push the update

Wand Maker
  • 18,476
  • 8
  • 53
  • 87
0

Using “git commit -a”

If you intend that your next commit should record all modifications of tracked files in the working tree and record all removals of files that have been removed from the working tree with rm (as opposed to git rm), use git commit -a, as it will automatically notice and record all removals. You can also have a similar effect without committing by using git add -u.

0

First:

rm testfile1.php

Then:

git add .
git commit -m 'message'
git push

In my daily work, regardless of creating, modifying or deleting files, the last three steps are same. It works fine for me.

gzc
  • 8,180
  • 8
  • 42
  • 62