I'm using latest nightlies of both EGit (0.8.0.201005300830) and JGit (0.8.0.201005300828).

I have a "usability" (or "understanding") problem about cloning repositories and pushing back changes.

Scenario:
* In workspace A, I create a new project and use the "Share Project..." to "elevate" it to a local git managed one.
* In workspace B (on another computer), I clone the repo from Workspace A
* Working on files of workspace B, committing them to git repo on B
* Finally pushing HEAD back to workspace A

So far so good, no problems reported, everything green.

However, now, opening up workspace A is "strange":
1) All files that were "pushed" to repo connected with workspace A get a decorator "modified". However, the modification is the wrong way round: If I do a "Compare To git index", it looks as if I "undid" the changes in workspace A. Also, if I do a "commit" now on workspace A, the pushed changes from workspace B are "reverted"!
2) The only way to get everything "right" again in workspace A is by doing a "Reset..." with reset type "hard" - causing of course all changes that I did on workspace A in the meantime to be overridden!

In short: To me, it seems that the scenario "pushing into a local repo" is not really supported. Do you confirm or am I just misunderstanding something?

> * The only way to get everything "right" again in workspace A is by doing
> a "Reset..." with reset type "hard" - causing of course all changes that I
> did on workspace A in the meantime to be overridden!

I observed that the commit from repo B is indeed there in repo A. You can
see that in
the History View. Therefore, if you do "Reset..." with reset type "hard" on
the current
HEAD everything should be as expected..
What exactly do you mean by "all changes that I did on workspace A in the
meantime" ?

> What exactly do you mean by "all changes that I did on
> workspace A in the meantime" ?

To be honest, I didn't verify (yet), but according to the description of a "reset type hard", that kind of reset means, that all changes in the workspace will be lost.

Example:

* workspace A is committed, no current changes
* changing File X in workspace A
* executing a hard reset
Wouldn't that mean, the changes on File X would be lost?
I assume they are. That would mean, that the workaround with "hard reset" is only acceptable, if workspace A and B are not being worked on at the same time (e.g. by two different developers).

But you should not push to a branch on another repository which has local
changes on that repository.
It is even not very common that you push to a branch which is checked out on
the remote.

A good practice is to have a dedicated branch as a target for pushes. You
can also create a new branches
on the remote with your push.

That's the part I have to get used to as a former SVN user: Branches are my friends and I should have many of them

All in all, I underestimated in the first place with the simple setup with two developers working on the same code where both have a workspace with their respective git repos, one created it originally and the other developer got a clone of it, it is not optional to use branches. It is a must.

In short, if I got it right now, it is crucial for both developers to work (and push) on separate branches and then merge the respective other branch into their workspace, right?

Or you share a public bare repository and all developers push their changes to that one.

It is a quite common usage pattern to do actual development in a private repository and share the changes via a public bare repository. This is useful especially when the developer repositories are not always online.

> * The only way to get everything "right" again in workspace A is by doing
> a "Reset..." with reset type "hard" - causing of course all changes that I
> did on workspace A in the meantime to be overridden!

I observed that the commit from repo B is indeed there in repo A. You can
see that in
the History View. Therefore, if you do "Reset..." with reset type "hard" on
the current
HEAD everything should be as expected..
What exactly do you mean by "all changes that I did on workspace A in the
meantime" ?

> What exactly do you mean by "all changes that I did on
> workspace A in the meantime" ?

To be honest, I didn't verify (yet), but according to the description of a "reset type hard", that kind of reset means, that all changes in the workspace will be lost.

Example:

* workspace A is committed, no current changes
* changing File X in workspace A
* executing a hard reset
Wouldn't that mean, the changes on File X would be lost?
I assume they are. That would mean, that the workaround with "hard reset" is only acceptable, if workspace A and B are not being worked on at the same time (e.g. by two different developers).

Stefan Lay wrote on Wed, 02 June 2010 05:06
> But you should not push to a branch on another repository which has local
> changes on that repository.
> It is even not very common that you push to a branch which is checked out on
> the remote.
>
> A good practice is to have a dedicated branch as a target for pushes. You
> can also create a new branches
> on the remote with your push.

That's the part I have to get used to as a former SVN user: Branches are my friends and I should have many of them :)

All in all, I underestimated in the first place with the simple setup with two developers working on the same code where both have a workspace with their respective git repos, one created it originally and the other developer got a clone of it, it is not optional to use branches. It is a must.

In short, if I got it right now, it is crucial for both developers to work (and push) on separate branches and then merge the respective other branch into their workspace, right?

Or you share a public bare repository and all developers push their changes to that one.

It is a quite common usage pattern to do actual development in a private repository and share the changes via a public bare repository. This is useful especially when the developer repositories are not always online.