i set up my workspace by importing a GIT repository and it worked fine. Now i make a change on a file and i want to commit it: if i right click on the file and select team --> commit, the commit works but i have the "staged" icon (the back-white star) close to the changed file within the eclipse explorer, but that file changes are not on the remote git , i just have it locally.
I worked with SVN and with it the commit are more easy to do. Maybe i miss something with GIT :)

How can i commit changes on the remote git repository? could anyone help me?

> i set up my workspace by importing a GIT repository and it worked fine.
> Now i make a change on a file and i want to commit it: if i right click on
> the file and select team --> commit, the commit works but i have the
> "staged" icon (the back-white star) close to the changed file within the
> eclipse explorer

Normally, after you have committed the change of the file, there should not
be the "staged" decoration anymore but the "tracked" decoration (Please see
the preferences for a description of the decoration). Maybe that is a
refresh problem?

> , but that file changes are not on the remote git , i just have it
> locally.

Git is a distributed version control system. That means that the import from
a remote location creates a complete repository on your local file system.
You can commit, branch and tag on this local repository. If you want to
bring your changes to a remote repository you normally use the command
"push". In EGit this is available at the context menu of a shared project.
Note that you may push to any remote repository, not necessarily the one you
imported from.

> I worked with SVN and with it the commit are more easy to do. Maybe i miss
> something with GIT :)

I recommend you to have a look at some introductory text, e.g. http://progit.org/book/ Many things are different to SVN in a distributed
version control system like Git.

I am having the same problem with confusion between dirty/staged states of a modified file after a commit. I'm pretty sure it's not a refresh issue. I am also new to both git and Egit, but I did a little investigation using git status from the command line.

After making a change to a file and saving, it gets a "dirty" decoration in Eclipse. git status says the file is "Changed but not updated".

After performing a commit in Eclipse, the "dirty" decoration is removed and "staged" is added. git status has file under "Changes to be committed:". This means staged, right?

At this point, I have to stop using Eclipse and do a commit from the command line, in order to get the staged file commited. Trying to commit again in Eclipse just gives the "nothing to commit" message.

What I don't get is how the history (right-click project > Team > Show in Resource History) can show all the things I've committed in different commits, but when I 'git status' on the command line, all those files I've committed are listed as modified/staged. 'git commit -a' indeed lists them all as having changes ready to commit.

Also, history (right-click project > Team > Show in Resource History) will show, for each item in the history, all the actions for each file, be it adds, deletes, ignores - whatever. 'git log' on the CL shows those commits but not files affected by the commit.

I don't know a heck of a lot about git yet, so I'll just ask: is EGit making all these commits to the index and not to the repo? Does git have the ability to track commits to the index (like a subcommit or something) and commits to the repo? If so, does EGit have some other hidden thing to make a true commit to the repo?

OK I think I figured it out. I think it's permission changes. What?! Yes, that's what I said.

So like I said, I had a bunch of 'staged' (*) symbols on just about everything, and the commit dialog was showing nothing to commit. So I went to command line, ran a 'git commit,' typed my message, and made the commit. I went back into Aptana/Eclipse and all the little icons went to the happy yellow can (I love the happy yellow can, by the way). I again reviewed the history. Nothing different about the latest commit. I clicked on one of the files - .htaccess to be specific - and read the message about it. Lo and behold:

OK, first of all, does the git repo really care about permissions?! Wouldn't the permissions inherit whatever they are on the target system when someone clones the repo?

Second, should I file a bug about the commit dialog in EGit? Seems it should check the permissions and allow a commit of a file whose permissions have changed but whose content has not necessarily changed. The project explorer clearly knows about permission changes. Did the dialog devs try to write their own 'is_this_dirty' method for just the dialog?

I think the problem here is that eclipse is displaying the file as modified (because of the permissions change) but you are not able to commit that change using eGit itself - to rectify the problem you must do a manual commit from the command line.

James has written a good walk through of how to reproduce the error in #312164.