Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EGit / JGit » [EGit] clone and push back process problems
[EGit] clone and push back process problems [message #537002] Mon, 31 May 2010 20:24 Go to next message
Kay Huber is currently offline Kay HuberFriend
Messages: 36
Registered: July 2009
Member
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 21:23]

Report message to a moderator

Re: [EGit] clone and push back process problems [message #537110 is a reply to message #537002] Tue, 01 June 2010 10:59 Go to previous messageGo to next message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
>
> 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 #537145 is a reply to message #537002] Tue, 01 June 2010 12:55 Go to previous messageGo to next message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
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 #537146 is a reply to message #537145] Tue, 01 June 2010 12:56 Go to previous messageGo to next message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
Hi Kay,
> Hi Kai,
Sorry for the typo!
Re: [EGit] clone and push back process problems [message #537282 is a reply to message #537145] Tue, 01 June 2010 19:05 Go to previous messageGo to next message
Kay Huber is currently offline Kay HuberFriend
Messages: 36
Registered: July 2009
Member
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 #537380 is a reply to message #537282] Wed, 02 June 2010 09:06 Go to previous messageGo to next message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
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.

> * 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?

Yes, in this case the changes are lost.

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.
Re: [EGit] clone and push back process problems [message #537399 is a reply to message #537380] Wed, 02 June 2010 10:22 Go to previous messageGo to next message
Kay Huber is currently offline Kay HuberFriend
Messages: 36
Registered: July 2009
Member
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 Smile

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 #537482 is a reply to message #537399] Wed, 02 June 2010 15:17 Go to previous message
Matthias Sohn is currently offline Matthias SohnFriend
Messages: 1268
Registered: July 2009
Senior Member
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.

For ways how to share see e.g. http://www.jedi.be/blog/2009/05/06/8-ways-to-share-your-git- repository/
Re: [EGit] clone and push back process problems [message #580842 is a reply to message #537002] Tue, 01 June 2010 10:59 Go to previous message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
>
> 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 12:55 Go to previous message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
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 #580870 is a reply to message #537145] Tue, 01 June 2010 12:56 Go to previous message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
Hi Kay,
> Hi Kai,
Sorry for the typo!
Re: [EGit] clone and push back process problems [message #580913 is a reply to message #537145] Tue, 01 June 2010 19:05 Go to previous message
Kay Huber is currently offline Kay HuberFriend
Messages: 36
Registered: July 2009
Member
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 #580995 is a reply to message #537282] Wed, 02 June 2010 09:06 Go to previous message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
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.

> * 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?

Yes, in this case the changes are lost.

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.
Re: [EGit] clone and push back process problems [message #581011 is a reply to message #537380] Wed, 02 June 2010 10:22 Go to previous message
Kay Huber is currently offline Kay HuberFriend
Messages: 36
Registered: July 2009
Member
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
Re: [EGit] clone and push back process problems [message #581052 is a reply to message #537399] Wed, 02 June 2010 15:17 Go to previous message
Matthias Sohn is currently offline Matthias SohnFriend
Messages: 1268
Registered: July 2009
Senior Member
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.

For ways how to share see e.g. http://www.jedi.be/blog/2009/05/06/8-ways-to-share-your-git- repository/
Previous Topic:[EGit] clone and push back process problems
Next Topic:NPE when pasting github URL in push wizard
Goto Forum:
  


Current Time: Fri Mar 29 05:52:52 GMT 2024

Powered by FUDForum. Page generated in 0.02874 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top