Renamed files inside git

Question

I am a new programmer in a team. And at my first day I have this renamed file inside a stage, ready to be committed by git:

 $ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   .gitignore
        new file:   reports/SQLS.rar
        renamed:    account/enter_rules.php -> enter_rules.old.php

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)       
        deleted:    account/enter_rules.old.php

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        account/enter_rules.php

For the first 2 lines I have no problem. I know what is going on. But for the last one renamed:, I am not sure what should be done . The system is working good.

Inside the work directory I have:

account/enter_rules.php

I can not find the enter_rules.old.php file.

It seems the other programmer have created a copy from the file, named the actual as .old, made some tests and new code, than staged the changes and forgot to commit. Than he manually deleted the old.php

What should be the best approach to deal with this situation? I would like to put git status clear before to start to work on it and make my own changes.

I found this post but I am not sure if I should or could commit in my situation. Handling file renames in git

---

After read all suggestions, that helped me a lot, this is what I did:

1. I just made a copy (only for safe) from the file enter_rules.php
2. I "told" to git (to the INDEX) that the file name had been changed. $git commit -m "committing name changes". At this point git dont know that .old was deleted.
3. Then I typed $git rm "account/enter_rules.old.php" to solve the line:Changes not staged for commit: . In the same way we use $git add . to "tell" git to track a <file>, we should use $git rm <file> to "tell" git to forget this <file>.
4. Then I typed $git status and I got the GREEN message: deleted: account/enter_rules.old.php. So I should tell to the index, that the .old file was removed. I typed $git commit -m "committing delete changes"
5. Now git knows that enter_rules.php was renamed to enter_rules.old.php and then enter_rules.old.php was removed (deleted).
6. Then I solved the last line (Untracked files:). I just told to git that a new file was created and it calls enter_rules.php. I added and committed as it should be.

All suggestions helped me to solve the issue, so I will try to be fair and will give the check to whose that has less point.

Answer 1

It seems clear to me what happened here:

In the initial state there were two files account/enter_rules.php and account/enter_rules.old.php.

Your colleague must have done something like this:

git rm account/enter_rules.old.php
git mv account/enter_rules.php account/enter_rule.old.php

then edited a new account/enter_rules.php and left it unstaged.

If you are ok with the changes just

git add account/enter_rules.php
git commit

else

rm account/enter_rules.php
git reset HEAD

to undo his changes.

What sound strange to me is why are you working on a colleague's clone of the repository with uncommitted changes?

Answer 2

Though git says that enter_rules.old.php was renamed, it also says that it was deleted below:

Changes not staged for commit:   (use "git add/rm <file>..." to update
what will be committed)   (use "git checkout -- <file>..." to discard
changes in working directory)       
         deleted:    account/enter_rules.old.php

This means that the file is gone, and in order for git to apply that deletion to the repository, the action of removing it must be included in your commit. Because the change is tracked, but not staged, you can perform this with a simple command (described below in part 3).

1. Add the file in account/enter_rules.php using git add account/enter_rules.php.
2. If you run git status again, enter_rules.old.php should be marked for deletion, and account/enter_rules.php should be staged to be committed.
3. Run git commit --all to commit all of your staged changes.

By running git commit --all, this will also stage the deletion that your co-worker performed but did not himself / herself commit.

It sounds like your co-worker used git mv to rename the file, and then deleted it but did not stage the deletion.

Answer 3

Git doesn't work on the files in your working folder. Instead, if works on something called "index". That means you can change files, put them in the index ("soon, I'd like to ...") and make the index permanent with git commit.

The main advantage here is that you can collect many changes in the index with individual commands (like when you've made several changes and would like to put them into individual commits). This process is called "staging". git add works on the index, for example.

What happened in your case is:

1. You renamed the file (probably in your IDE) and told Git to "stage" the change. Git remembers this in the index.
2. You deleted the file without telling Git
3. You got a copy of account/enter_rules.php from somewhere and copied that into your working folder, also without telling Git.

For Git, the situation is now that it knows that there once was a file enter_rules.old.php which you wanted to commit. You can do that because Git remembers enough to actually do that.

At the same time, your workspace has changed a lot. The staged file is gone and a new copy has appeared. Since Git can't read your mind, it doesn't try to figure out what this might mean. It just lists the facts.

Now to clean up:

To make Git forget about the rename to enter_rules.old.php, use git reset HEAD enter_rules.old.php

It should now remember that account/enter_rules.php is tracked. If you changed this file, it will show it as changed. Run git status to make sure.