Git creates files but then strangely deletes them again

Question

I'm using Git now from my Windows machine.

I clone the repo, do some changes and push.

Until here everything works fine.

But when I commit for example a test.txt in my local folder and push,

then look into my remote repo and do

git log: shows the commit message

git status: file deleted "test.txt"

What's that?

Why 'file deleted "test.txt"'?

The file should be created!

I then can commit the change of the file's deletion and when I pull to my local folder again, the file get's deleted again in the local folder as well.

Any Help?

Yours, Joern.

When you say "nothing has changed", do you mean that the copy of the remote repo is a non-bare repository and that the working directory has not changed? (Typically, you push to a bare repository that does not have working files; push will not modify those files if they do exist.) — William Pursell, Feb 04 '11 at 20:04
hm, important to say is, I'm a Git newb; at my last work we used Git but all was preconfigured. It was possible to update the whole repo, even though the files existed, and when it existed and was modified it was updated and you could show up the differences. — Joern Akkermann, Feb 05 '11 at 15:48

score 3 · Accepted Answer · edited Jun 20 '20 at 09:12

You mention that you use gitosis, but from the command output you provided my only conclusion is that your gitosis setup is COMPLETELY broken.

First thing I notice is that you are asked for a password, and it appears you entered it and the push continued on. The server should never ask for a password, if it does then its a sign that you aren't providing the correct ssh keypair to the server or the server is misconfigured and should result in an aborted push attempt since the account gitosis is using should not have a password set. By using a password it means you are overriding everything that gitosis is designed to do and you might as well just remove it because its not being used at all.

Second thing I noticed is you are pushing to /var/www/saris/.git which by standard naming convention indicates a non-bare repo. Again you seem to be going around everything gitosis does because gitosis only works with bare repos. In addition this is exactly why you see no changes on the server. When pushing to a non-bare repo the working tree is never updated so the effect you seem to be trying to get (updating a website in /var/www/saris) will not work. See https://git.wiki.kernel.org/index.php/GitFaq#non-bare and http://toroid.org/ams/git-website-howto for more information about non-bare repos and managing websites with git.

Additionally I like to point out whenever possible that gitosis is unmaintained and deprecated by the git community in favor of the superior gitolite.

EDIT: You've completely removed the original question and replaced it with another unrelated question and lost all the original details. You should have just created a new question but I'll answer your new question anyway.

Your new question is essentially one of the most basic and common git questions. It is asked so often that it has its part of the GitFaq which I've copied to here and even linked when I answered your original question.

Why won't I see changes in the remote repo after "git push"?

The push operation is always about propagating the repository history and updating the refs, and never touches the working tree files. In particular, if you push to update the branch that is checked out in a remote repository the files in the work tree will not be updated.

This is a precautionary design decision. The remote repository's work tree may have local changes, and there is no way for you, who are pushing into the remote repository, to resolve conflicts between the changes you are pushing and the ones in the work tree. However, you can easily make a post-update hook to update the working copy of the checked out branch. The reason for not making this a default example hook is that they only notify the person doing the pushing if there was a problem. The latest draft post-update hook for this is at http://utsl.gen.nz/git/post-update, which deals with almost all cases, apart from where there is already a conflicted merge on the remote side (as git-stash cannot currently stash this). It also fails to work in instances where it could, such as none of the files are actually conflicting.

A quick rule of thumb is to never push into a repository that has a work tree attached to it, until you know what you are doing.

If you are sure what you are doing, you can do a "git reset --hard" on the side you pushed to. Note that this WILL lose ALL changes you made on that side, resetting the working tree to the newest revision you pushed. See this article about bare repositories for details.

Again please read http://toroid.org/ams/git-website-howto which I linked when I answered your first question. If you use that solution you will not have this problem.

in the start of the next week I will check my gitosis conf or change to gitolite, then I speak back. — Joern Akkermann, Feb 05 '11 at 20:58
thanks for your answer; I replaced the old question to save on questions, might be a consuetude from standard forums — Joern Akkermann, Feb 11 '11 at 17:38
I get the same error as in this question, even if I'll use your tutorial — Joern Akkermann, Feb 11 '11 at 19:00
You are using a bare repo on the remote right? Created with `git init --bare`? Your question describes a situation using two non-bare (normal) repos which is very different from the setup in the git-website-howto I linked. — Arrowmaster, Feb 11 '11 at 21:16
There was no --bare flag... only --shared, so I used --shared — Joern Akkermann, Feb 13 '11 at 11:00
You need to create the repo with `git init --bare` or `git --bare init`. If `git init --bare` does not work then you have an extremely old version of git and should upgrade. — Arrowmaster, Feb 15 '11 at 00:05

score 0 · Answer 2 · edited May 23 '17 at 10:33

0

When pushing you will get a reject error if your commits are not a fast-forward on the remote repo (e.g. someone else has pushed changes to the remote repo). The easiest way to correct this is to do a git pull which will fetch the changes, and perform an automatic merge.

If you are using multiple branches Git, by default, tries to push all of them -- not just the current branch you are on. This can lead to some confusing messages that will show multiple success or rejected lines. This question has some configuration you can add to change this behavior.

edited May 23 '17 at 10:33

Community

1
1

answered Feb 05 '11 at 16:35

Uriah Carpenter

6,656
32
28

This looks like network (or remote disk space) error, not like fast-forward error. Fast forward errors usually print large explanation (which can be switched in the config, AFAIR, though). – Alexander Gladysh Feb 05 '11 at 16:40
so I enter git config push.default - that hasn't change a thing – Joern Akkermann Feb 05 '11 at 16:41
I had permissions errors before, but that was easy to fix by chowning the repo to git:www-data – Joern Akkermann Feb 07 '11 at 14:48

Git creates files but then strangely deletes them again

2 Answers2