Community
Participate
Working Groups
From bug 281394 the idea has come up that there needs to be a git equivalent to the existing CVS explorer. Wolfgang Werner suggested: Wouldn't it be best then to implement a "Git Repository Browsing" Perspective containing a "Git Repositories" View analogous to the CVS/SVN The top level nodes should be the individual repositories. Repositories can be added like with CVS/SVN. Below the repository nodes, the folder structure of the repositories contents should be displayed and have a context menu option on each tree node to "Check Out" or "Check Out as ...". "Check out as ..." gives the following options when using SVN: - Check out as new project using the New Projects Wizard - Check out as project in the Workspace - Check out into an existing project This provides all degrees of freedom there are, I think. That would also help new users switching to git as it behaves the same as when using CSV/SVN.
Created attachment 157562 [details] Mockup - New Git Repository Dialog A mock up how the 'Add Git Repository' dialog could look like. I stole the layout from subversive using the swt-balsamiq export (http://in.relation.to/Bloggers/InstantMockupForEclipseSWTApplications)
Created attachment 157563 [details] Mockup - Clone Repository wizard A mockup of a possible "Clone Repository"/"Check out as" dialog. Also heavily inspired by subversive.
I was going to put a Git Repositories view on my list of things to do for 0.8.0 The perspective is fine also.
I have added a very first implementation on Gerrit: http://egit.eclipse.org/r/344 I suggest to continue discussions using this bug.
Fantastic! I will review the initial cut of this. We should get something in soon and start iterating as we won't get it right first ;)
(In reply to comment #4) A giant leap for mankind. Excellent work. I have ironed out some bugs already. do you mind if I attach them as patches here? (Still having nightmares of Gerrit chasing me)
*** Bug 302742 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > (In reply to comment #4) > A giant leap for mankind. Excellent work. > > I have ironed out some bugs already. do you mind if I attach them as patches > here? (Still having nightmares of Gerrit chasing me) Hi Wim, Do it. I will be glad to review, integrate and push to Gerrit your fixes. Looking forward to your feedback. Mathias
Created attachment 163047 [details] Fixed recursive local repository scan returns too early A small one to check if this is the way of communicating patches thru bugzilla
(In reply to comment #9) > Created an attachment (id=163047) [details] > Fixed recursive local repository scan returns too early > > A small one to check if this is the way of communicating patches thru bugzilla It looks like you would expect some sort of nesting of Git Repositories. Is this correct? If yes, it still sounds a bit exotic to me.... Anyway, perhaps we should have a checkbox on the UI saying something like "Search for nested Directories" and skip the return only if this box is checked. Or, if it is really exotic, may be the user must go to the nested Repository directly... If we always search down the hierarchy, there will be a lot of unneccessary file system traversal... What do you think?
> It looks like you would expect some sort of nesting of Git Repositories. Is > this correct? If yes, it still sounds a bit exotic to me.... No not really. The old code would return if the first child directory of a given directory would be a git repository. Now it continues to examine to other child directories on the same level. I agree that nested repositories are exotic.
Created attachment 163116 [details] Fixed recursive local repos search Added that a git repository will not be recursed.
(In reply to comment #12) > Created an attachment (id=163116) [details] > Fixed recursive local repos search > > Added that a git repository will not be recursed. Thanks, this makes things a bit clearer. So this would fix the situation where you have two Git Repositories in the same directory (i.e. two ".git" directories as subdirectories of the same directory in the file system). If that is actually the use case, then we would have to change the Repositories view, since I actually assumed that a given directory can only ever contain one ".git" subdirectory identifying the Repository (and that's actually what is imposed by the behavior of the git init command and clone wizard). Can you clarify?
(In reply to comment #13) > (In reply to comment #12) > > Created an attachment (id=163116) [details] [details] > > Fixed recursive local repos search > > > > Added that a git repository will not be recursed. > > Thanks, this makes things a bit clearer. So this would fix the situation where > you have two Git Repositories in the same directory (i.e. two ".git" > directories as subdirectories of the same directory in the file system). If > that is actually the use case, then we would have to change the Repositories > view, since I actually assumed that a given directory can only ever contain one > ".git" subdirectory identifying the Repository (and that's actually what is > imposed by the behavior of the git init command and clone wizard). Can you > clarify? Here is the way to think about this. In current work flows, and even with Git workflows, I tend to have more than one .git repository I use for a particular workspace. Especially if the projects are related and dependendent on each other. So for an example, as a WTP user, I may need to have both the commons.git and sourceediting.git repositories cloned, and pieces of each of those repositories imported. Because sourceediting has some dependencies on projects in commons. Also, the current CVS and SVN explorers available, allow multiple repositories to be added/removed/viewed all within the the same perspective and view.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > Created an attachment (id=163116) [details] [details] [details] > > > Fixed recursive local repos search > > > > > > Added that a git repository will not be recursed. > > > > Thanks, this makes things a bit clearer. So this would fix the situation where > > you have two Git Repositories in the same directory (i.e. two ".git" > > directories as subdirectories of the same directory in the file system). If > > that is actually the use case, then we would have to change the Repositories > > view, since I actually assumed that a given directory can only ever contain one > > ".git" subdirectory identifying the Repository (and that's actually what is > > imposed by the behavior of the git init command and clone wizard). Can you > > clarify? > > Here is the way to think about this. In current work flows, and even with Git > workflows, I tend to have more than one .git repository I use for a particular > workspace. Especially if the projects are related and dependendent on each > other. So for an example, as a WTP user, I may need to have both the > commons.git and sourceediting.git repositories cloned, and pieces of each of > those repositories imported. Because sourceediting has some dependencies on > projects in commons. > > Also, the current CVS and SVN explorers available, allow multiple repositories > to be added/removed/viewed all within the the same perspective and view. Agreed; so you may have imported sourceediting to some folder <git>/sourceediting and commons to some folder <git>/commons (both with a subdirectory /.git beneath them). Now, with the current implementation, you could point the search dialog to the common parent directory (<git>) of these repositories and you would be offered both repositories for adding to the repositories view (since the recursion only stops once a ".git" child directory is encountered).
(In reply to comment #15) > subdirectory /.git beneath them). Now, with the current implementation, you > could point the search dialog to the common parent directory (<git>) of these > repositories and you would be offered both repositories for adding to the And with current implementation you mean my patch ;-)? If not then no, because, assume you have 3 children in the <git> directory. The first one (inside the for-each-child loop) is a git directory. Then if you return, the other directories are not examined because you leave the method with return in the for-each-child loop.
(In reply to comment #16) > (In reply to comment #15) > > > subdirectory /.git beneath them). Now, with the current implementation, you > > could point the search dialog to the common parent directory (<git>) of these > > repositories and you would be offered both repositories for adding to the > > And with current implementation you mean my patch ;-)? If not then no, because, > assume you have 3 children in the <git> directory. The first one (inside the > for-each-child loop) is a git directory. Then if you return, the other > directories are not examined because you leave the method with return in the > for-each-child loop. I actually meant without your patch. The method may return, but it is called recursively. I actually tested the behavior I wrote about in comment 15.
(In reply to comment #17) > recursively. I actually tested the behavior I wrote about in comment 15. I apologize if I came across as a smart-ass. It was not my intention to irritate or disrespect you in any way. If you look at statement 1444 it takes the children from <root>. Now assume <root> contains two directories and both directories are git repositories. On 1451 it determines that the first directory is a .git directory. It adds this to the list and returns on 1453. The second directory does not get processed. In my patch I have removed the return on 1453 and added some logic to 1455 to not recurse into git repositories. 1432 /** 1433 * 1434 * @param root 1435 * @param strings 1436 * @param monitor 1437 */ 1438 public static void recurseDir(File root, TreeSet<String> strings, 1439 IProgressMonitor monitor) { 1440 1441 if (!root.exists() || !root.isDirectory()) { 1442 return; 1443 } 1444 File[] children = root.listFiles(); 1445 for (File child : children) { 1446 if (monitor.isCanceled()) { 1447 return; 1448 } 1449 1450 if (child.exists() && child.isDirectory() 1451 && RepositoryCache.FileKey.isGitRepository(child)) { 1452 strings.add(child.getAbsolutePath()); 1453 return; 1454 } 1455 if (child.isDirectory()) { 1456 monitor.setTaskName(child.getPath()); 1457 recurseDir(child, strings, monitor); 1458 } 1459 } 1460 1461 }
Created attachment 163298 [details] Example screenshot
(In reply to comment #18) > (In reply to comment #17) > > recursively. I actually tested the behavior I wrote about in comment 15. > > I apologize if I came across as a smart-ass. It was not my intention to > irritate or disrespect you in any way. > <snip> > Hi Wim, not offense taken at all. To the contrary, I hope I didn't sound impatient or idignant here. Meanwhile I wonder if we talk about the same thing. What I wanted to say is that the current implementation covers the use case shown in the attached screenshot. The reason why this works is that method RepositoryCache.FileKey.isGitRepository(child) acutally returns true on the ".git"-directory (and not on the working directory). Since each ".git"-directory is in it's own parent directory, we should be fine. If the screenshot does not cover your use case, could you please add some visualization of the directory structure where you have the problem?
(In reply to comment #20) mmm.. Your visual looks correct but is not working for me. I wonder what I did to get the following. Do you have any updates that are not in HEAD? http://screencast.com/t/NzU4ODJiM
I just tried the latest integration build from Hudson, and noticed the repositories view was vailable. First the good: 1. I pointed it to a Folder outside of Eclipse and it correctly found all the git repositories. 2. I was able to import several exist projects into my eclipse workspace. 3. It correctly assoicated all the team sharing for git with those projects. The bad: 1. No ability to Explorer the actual project's. 2. No ability to browse particular branches/tags. 3. Not integrated with existing git Import wizard. But over all not bad for a first cut.
Yes, I agree, good progress is being made. You should also be able to add a repository to the view without necessarily importing it. This is the behavior that the CVS repository view has and I think it's quite nice.
(In reply to comment #21) > (In reply to comment #20) > > mmm.. Your visual looks correct but is not working for me. I wonder what I did > to get the following. Do you have any updates that are not in HEAD? > > http://screencast.com/t/NzU4ODJiM Hi Wim, thanks for the screencast... Now, it looks like we are back to what I called "nested respositories" above. Looking at the search dialog with your correction, it finds several repositories: .../workspaces/nntpgit/.git .../workspaces/nntpgit/egit/.git .../workspaces/nntpgit/gitcvs/.git <...more...> so the egit and gitcvs repositories are nested within the nntpgit repository. Apparently, having this kind of setup is not so exotic as I thought. In that case, I still think we should add a checkbox allowing a "deep" search and skip the return only if this box is checked in order to avoid unneccessary deep traversals. Oh, and I like the "Toggle Select" button!
(In reply to comment #22) > I just tried the latest integration build from Hudson, and noticed the > repositories view was vailable. > > First the good: > > 1. I pointed it to a Folder outside of Eclipse and it correctly found all the > git repositories. > > 2. I was able to import several exist projects into my eclipse workspace. > > 3. It correctly assoicated all the team sharing for git with those projects. > > The bad: > > 1. No ability to Explorer the actual project's. > > 2. No ability to browse particular branches/tags. > > 3. Not integrated with existing git Import wizard. > > But over all not bad for a first cut. As for the "bad" section: > 1. No ability to Explorer the actual project's. Actually, when I look at it, the current implementation is confusing, as the end user will probably assume that the "Existing projects" node is just a display of the folders in the working directory, but in fact it is really a list of projects found by traversion the working directory and finding ".project" files there (and that's why there is no trying to display children etc). Perhaps, instead of the "Existing projects" node, we should probably have a "Working directory" node which simply allows to browse the structure of that directory (no notion of projects here)... The "Import Existing Projects" wizard could then be started on any directory within the working directory. Is that about the right direction? > 2. No ability to browse particular branches/tags. I'll have to familiarize myself more with the inner workings of JGit here, but agree that this would be cool. I'll try to look into it ASAP. > 3. Not integrated with existing git Import wizard. This is a glitch, sorry. I did implement some integration, but this is actually causing problems (you will lose repositories outside the workspace when you clone a new one). I have prepared a fix, but currently there are problems with Gerrit, so I couldn't push it yet.
(In reply to comment #23) > Yes, I agree, good progress is being made. > > You should also be able to add a repository to the view without necessarily > importing it. This is the behavior that the CVS repository view has and I think > it's quite nice. What exactly do you mean by "importing" here? It is already possible to add a repository to the view without importing projects. However, the repository must be available on the local file system (the view simply stores directory names to build the root nodes). Is the requierment to instantiate a repository using a Git URI?
(In reply to comment #24) > case, I still think we should add a checkbox allowing a "deep" search and skip > Oh, and I like the "Toggle Select" button! I see. My base directory was also a repository... All of my git repositories where created by the import wizard. If I made a nested repositories so will a lot of other first time users, I suspect. > case, I still think we should add a checkbox allowing a "deep" search and skip > Oh, and I like the "Toggle Select" button! Okay, I will add the select all & deep search toggle and update the patch.
Created attachment 163387 [details] Search dialog additions Made progress indication more meaningful Made searchdialog nicer to look at. Added tableitem (de)select all toggle Added deepscan for nested repositories toggle I got rid of the GridDataFactory, maybe you don't like that. If you are very fond of it then let me know. The state of the toggle and the root directory should be stored in the dialogpreferences. Please look at the updateDirStrings method in the reposview. Don't know why it calls the recursedir method and if the deepscan is in its place there. If you are happy with it I will clean up the source.
(In reply to comment #25) > > As for the "bad" section: > > > 1. No ability to Explorer the actual project's. > > Actually, when I look at it, the current implementation is confusing, as the > end user will probably assume that the "Existing projects" node is just a > display of the folders in the working directory, but in fact it is really a > list of projects found by traversion the working directory and finding > ".project" files there (and that's why there is no trying to display children > etc). Perhaps, instead of the "Existing projects" node, we should probably have > a "Working directory" node which simply allows to browse the structure of that > directory (no notion of projects here)... The "Import Existing Projects" wizard > could then be started on any directory within the working directory. > Is that about the right direction? Yes. I should be able to browse any folder that is there, whether it is an eclipse project or not. If I import a folder it should go through the Create Project Wizard if it can't find a .project file already. > > > 2. No ability to browse particular branches/tags. > > I'll have to familiarize myself more with the inner workings of JGit here, but > agree that this would be cool. I'll try to look into it ASAP. Very cool. > > > 3. Not integrated with existing git Import wizard. > > This is a glitch, sorry. I did implement some integration, but this is actually > causing problems (you will lose repositories outside the workspace when you > clone a new one). I have prepared a fix, but currently there are problems with > Gerrit, so I couldn't push it yet. Cool. I'll keep updating periodically and testing as the updates come in.
(In reply to comment #28) > Created an attachment (id=163387) [details] On a side note Wim, we should teach you how to use Gerrit in the future. Find me on Skype one of these days.
(In reply to comment #26) > What exactly do you mean by "importing" here? It is already possible to add a > repository to the view without importing projects. However, the repository must > be available on the local file system (the view simply stores directory names > to build the root nodes). Is the requierment to instantiate a repository using > a Git URI? Yes, that would be ideal. For example, it would be nice to browse the contents of the remote repo without having to do an important. I can do this within the CVS repositories view by adding some repo like dev.eclipse.org:/cvsroot/eclipse and browse around before I decide to import anything. Does that make sense?
Next round: http://egit.eclipse.org/r/502 has quite some fixes/improvements. I also integrated Jim Wongmans great work.
Thanks, I'll do the review in about an hour. Looks good so far, need to just go through it in a bit more detail.
(In reply to comment #32) > I also integrated Jim Wongmans.. haha, I actually like that name! One more suggestion, the Search Dialog needs a border around the tab: line 234: tv = CheckboxTableViewer.newCheckList(main, SWT.BORDER);
I pushed most of Mathias' changes. Thanks Mathias. If we are going to make revisions to this view and perspective, please open new bugs for discussion and actionable items. > 20100401
