[EGit] clone and push back process problems [message #537002] |
Mon, 31 May 2010 16:24  |
Eclipse User |
|
|
|
Hi all!
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?
Thanks for any comments.
Regards
Kay
[Updated on: Mon, 31 May 2010 17:23] by Moderator
|
|
|
|
|
|
|
|
Re: [EGit] clone and push back process problems [message #537399 is a reply to message #537380] |
Wed, 02 June 2010 06:22   |
Eclipse User |
|
|
|
Got it, thanks for the link.
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?
Thanks for the hints, very appreciated!
Regards
Kay
|
|
|
|
Re: [EGit] clone and push back process problems [message #580842 is a reply to message #537002] |
Tue, 01 June 2010 06:59  |
Eclipse User |
|
|
|
>
> 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?
>
I could reproduce that. This is clearly a bug. The push is done (the commit
is there and the HEAD is updated) but the index and the working tree are not
updated.
I'll open a bug in bugzilla.
Thanks,
Stefan
|
|
|
Re: [EGit] clone and push back process problems [message #580861 is a reply to message #537002] |
Tue, 01 June 2010 08:55  |
Eclipse User |
|
|
|
Hi Kai,
I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=315205
> * 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" ?
Regards,
Stefan
|
|
|
|
Re: [EGit] clone and push back process problems [message #580913 is a reply to message #537145] |
Tue, 01 June 2010 15:05  |
Eclipse User |
|
|
|
Hi Stefan
Thanks for your prompt reply and verification.
> 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).
Regards
Kay
|
|
|
|
Re: [EGit] clone and push back process problems [message #581011 is a reply to message #537380] |
Wed, 02 June 2010 06:22  |
Eclipse User |
|
|
|
Stefan Lay wrote on Wed, 02 June 2010 05:06
> I found out that the push works as designed. Please have a look at
> https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_s ee_changes_in_the_remote_repo_after_.22git_push.22.3F
> which contains a detailed explanation.
Got it, thanks for the link.
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?
Thanks for the hints, very appreciated!
Regards
Kay
|
|
|
|
Powered by
FUDForum. Page generated in 0.05964 seconds