Community
Participate
Working Groups
Created attachment 204689 [details] YourKit snapshot 1.2.0.201110021920 I had branch R3_6_maintenance of org.eclipse.jdt.ui checked out from git.eclipse.org/gitroot/jdt/eclipse.jdt.ui.git . On the project, I chose Replace With > Branch, Tag, or Reference..., and selected Remote Tracking > origin/R3_7_maintenance. This took very long without any progress and a lot of processing in the UI thread (IDE not usable). I tried to cancel the "Discard Changes" job after more than 1h, but this didn't work (job continued). After another 10 min., I killed the Eclipse process.
Can you extract a stackdump from that?
Created attachment 204738 [details] text version of snapshot I tried to expand all interesting branches. The CPU hogs are file system accesses, most notably java.io.WinNTFileSystem.getLength(File) java.io.WinNTFileSystem.getBooleanAttributes(File) java.io.WinNTFileSystem.getLastModifiedTime(File)
Fix proposed: http://egit.eclipse.org/r/4347
Possibly related to bug 338654 .
merged as c0fddc53ff908a0a37d78760e3465ae179ba8250 I am wondering if you really wanted to use "Replace With" here or if you rather meant to checkout the other branch. "Replace With" corresponds to "git checkout <tree-ish> -- <pathspec>" which only replaces files matching the given pathspec whereas "Switch To" corresponds to "git checkout branch" which will checkout the complete tree and also move HEAD to this branch or in case of a remote tracking branch to the commit the remote tracking branch is pointing to.
(In reply to comment #5) > merged as c0fddc53ff908a0a37d78760e3465ae179ba8250 > > I am wondering if you really wanted to use "Replace With" here or if you rather > meant to checkout the other branch. > > "Replace With" corresponds to "git checkout <tree-ish> -- <pathspec>" which > only replaces files matching the given pathspec whereas "Switch To" corresponds > to "git checkout branch" which will checkout the complete tree and also move > HEAD to this branch or in case of a remote tracking branch to the commit the > remote tracking branch is pointing to. From CVS I'm used to this workflow: 1. apply a patch 2. test it 3. on the affected resource(s) do a Replace With > HEAD Revision when done But maybe it's time to learn another workflow.
(In reply to comment #6) > From CVS I'm used to this workflow: > 1. apply a patch > 2. test it > 3. on the affected resource(s) do a Replace With > HEAD Revision when done If I'm doing this, I usually replace the files with the version in the index. I have no idea if this is faster or if it's faster to replace something with HEAD. I suppose I usually _individually_ select the files instead of the entire project (like Markus did in comment 0) so there is less churn for me?
(In reply to comment #6) > (In reply to comment #5) > > merged as c0fddc53ff908a0a37d78760e3465ae179ba8250 > > > > I am wondering if you really wanted to use "Replace With" here or if you rather > > meant to checkout the other branch. > > > > "Replace With" corresponds to "git checkout <tree-ish> -- <pathspec>" which > > only replaces files matching the given pathspec whereas "Switch To" corresponds > > to "git checkout branch" which will checkout the complete tree and also move > > HEAD to this branch or in case of a remote tracking branch to the commit the > > remote tracking branch is pointing to. > > From CVS I'm used to this workflow: > 1. apply a patch > 2. test it > 3. on the affected resource(s) do a Replace With > HEAD Revision when done > > But maybe it's time to learn another workflow. With Git you usually develop a patch in a new local brach / fetch an existing patch to a new local branch. After finishing testing you can switch back to master branch.
(In reply to comment #5) > "Replace With" corresponds to "git checkout <tree-ish> -- <pathspec>" Yes, I really needed that one. Dani, Remy: There's a difference in behavior between Eclipse CVS and EGit: - In Eclipse CVS, Replace With > ... also switched to that branch. - In EGit, Replace With > ... only replaces the file contents, but never switches branches.
(In reply to comment #9) > Dani, Remy: There's a difference in behavior between Eclipse CVS and EGit: > - In Eclipse CVS, Replace With > ... also switched to that branch. > - In EGit, Replace With > ... only replaces the file contents, but never > switches branches. You're absolutely right, Markus. I don't use the 'Replace With' submenu much with CVS or Git but I do recall seeing what you have described in the past.
> Dani, Remy: There's a difference in behavior between Eclipse CVS and EGit: > - In Eclipse CVS, Replace With > ... also switched to that branch. > - In EGit, Replace With > ... only replaces the file contents, but never > switches branches. Yes, I know. But since I replace HEAD with HEAD this is essentially the same in CVS and EGit.
Verified in 1.2.0.201110190928: much faster now!
(In reply to comment #6) > (In reply to comment #5) > > merged as c0fddc53ff908a0a37d78760e3465ae179ba8250 > > > > I am wondering if you really wanted to use "Replace With" here or if you rather > > meant to checkout the other branch. > > > > "Replace With" corresponds to "git checkout <tree-ish> -- <pathspec>" which > > only replaces files matching the given pathspec whereas "Switch To" corresponds > > to "git checkout branch" which will checkout the complete tree and also move > > HEAD to this branch or in case of a remote tracking branch to the commit the > > remote tracking branch is pointing to. > > From CVS I'm used to this workflow: > 1. apply a patch > 2. test it > 3. on the affected resource(s) do a Replace With > HEAD Revision when done > > But maybe it's time to learn another workflow. With git it shouldn't be necessary to manually select the affected resources again and do "replace with HEAD". If you intend to switch back to HEAD to throw away all uncommitted local changes in the working tree, instead just reset hard to HEAD, this shouldn't be slower compared to what you described. In order to test a patch I would do the following steps (actually I do them all the time using Gerrit code review for trading git commits instead of plain patches) - create local branch based on target branch (usually origin/master) this patch is aiming for - apply patch and commit it - test it - if test (and review) successful -> push to public repository - if this is not successful -> tell author what to improve - when I get improved patch from author -> apply this onto the commit previously created for this task and do commit amend to replace the previous commit - in order to switch to another task switch to another local branch So as a general rule I always use a local branch per independent task which is in progress. This way switching between tasks translates 1 to 1 to switching branches.
