Bugzilla – Full Text Bug Listing
| Summary: | [client][git] make clone git repo more friendly | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Felipe Heidrich <eclipse.felipe> |
| Component: | Client | Assignee: | Malgorzata Janczarska <malgorzata.tomczyk> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bokowski, malgorzata.tomczyk, susan, Szymon.Brandys, tomasz.zarna |
| Version: | 0.2 | ||
| Target Milestone: | 0.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 345307 | ||
|
Description
Felipe Heidrich
You are right. We will move the CloneRepo action to the Git repositories view and will try to make it more friendly. (In reply to comment #0) > After I clicked okay the dialog closed and there is no indication of what is > happening (no progress bar, no message in status line, anything). Bug 334140 and bug 341673 are about to change that. *** Bug 343325 has been marked as a duplicate of this bug. *** I find several things to be confusing about the git clone command: - it only clones the repository, it doesn't actually link it into my workspace. Presumably I'm to figure out how to do this using the status message that tells me where the cloned repo resides. Ideally it should just link automatically for me. - why is the icon ever present at all levels of the nav? To me it seems like a peer to "link project." It should just be visible when I'm at the nav root. Otherwise I'll have to navigate to the root in order to link to the cloned repo. Note that when we have a landing page (bug 343290) it can be even easier to create a project from a cloned repo. But until then, I think we should make the git clone command appear only in the nav root and it should do the link for you. (In reply to comment #4) > - it only clones the repository, it doesn't actually link it into my workspace. > Presumably I'm to figure out how to do this using the status message that > tells me where the cloned repo resides. Ideally it should just link > automatically for me. The problem is linking the entire repository might not be what you want. Maybe you're only interested in working on one project/folder in the repository. In egit this is a two step process, where you create clones, and then you can import folders from those clones into your workspace. I like this model because it allows the user to assemble an uncluttered list of the folders they actually care about rather than having to tunnel down through the whole repository. > - why is the icon ever present at all levels of the nav? To me it seems like a > peer to "link project." It should just be visible when I'm at the nav root. > Otherwise I'll have to navigate to the root in order to link to the cloned > repo. I would even be tempted to remove the clone command from the nav entirely, and just add a link in the header next to Navigator / Sites /Plugins to get to the clone view page. Otherwise we are going down the route of pulling lots of git functionality and scripts into the navigate page. Git Clone command will be moved to Git Clone UI at some point. However our Git Clone UI is not in a shape where we could choose any node from the working tree and link it to the workspace. Thus we have Git Clone command in Navigator UI. (In reply to comment #5) > The problem is linking the entire repository might not be what you want. Maybe > you're only interested in working on one project/folder in the repository. In > egit this is a two step process, where you create clones, and then you can > import folders from those clones into your workspace. If you are using the Git command line, you get the complete repository. IMO, this argues strongly for doing what Susan suggested. My guess would be that the two-step process in EGit is there because the Eclipse IDE treats projects in a special way, and you want to make sure that the "right thing" ends up at the project level. In general, I think it is more important to not surprise a typical Git user than it is to not surprise a typical Eclipse user. (In reply to comment #7) > If you are using the Git command line, you get the complete repository. On second thought I think that Git Clone should work in a similar way to Import command. We should select a folder in the workspace and clone a repo there. It would be a real console experience. However it means that Git service should understand file locations (URIs), i.e. Git Clone operations should get a folder location like /file/[folderPath] This is my idea of how could we solve the problem with linking leaving it as two step process 1. move git clone command to view with git clones list (it's now called git clones, maybe we should call it git repositories?) 2. add a link to git clones next to "Navigator Sites Plugins" 3. refresh the clones list when clone action is finished (actually it's already implemented) 4. add a link command to each repository in the list As for linking to subfolders of the repository I see one problem: we don't display repositories content anywhere. So if a user would like to link to a subfolder he would have to know exactly its path. (In reply to comment #10) > This is my idea of how could we solve the problem with linking leaving it as > two step process > 1. move git clone command to view with git clones list (it's now called git > clones, maybe we should call it git repositories?) > 2. add a link to git clones next to "Navigator Sites Plugins" > 3. refresh the clones list when clone action is finished (actually it's already > implemented) > 4. add a link command to each repository in the list I like this. > > As for linking to subfolders of the repository I see one problem: we don't > display repositories content anywhere. So if a user would like to link to a > subfolder he would have to know exactly its path. I had problems in the past where I couldn't see the git commands when I linked to repos that were below the main directory. Is this still the case, or is that problem not possible since we are now using Orion to do the clone. (In my case I had cloned using other git tooling so when I linked to a specific subdirectory Orion had no idea this was git. I had to link to the root to see the git commands). I think we should just add the link command to each repo, and if the user wants to look at something at a different level, they can add it to "favorites." That is how I work today, I have favorites to specific drill-down points where I do my work. (In reply to comment #11) > (In reply to comment #10) > > This is my idea of how could we solve the problem with linking leaving it as > > two step process > > 1. move git clone command to view with git clones list (it's now called git > > clones, maybe we should call it git repositories?) > > 2. add a link to git clones next to "Navigator Sites Plugins" > > 3. refresh the clones list when clone action is finished (actually it's > already > > implemented) > > 4. add a link command to each repository in the list > > I like this. We agreed for this approach some time ago. However I think that we should discuss the one described in comment 9. This approach would be consistent with our Import operation and is more handy IMO. > I think we should just add the link command to each repo, and if the user wants > to look at something at a different level, they can add it to "favorites." That > is how I work today, I have favorites to specific drill-down points where I do > my work. It looks like we would end up somewhere between EGit and console approach. Git Repositories UI would be this EGit part and linking a repo to the workspace root would take us to the console world. As I'm suggesting above we should make a step further and just clone repos pointing at a folder in the workspace (like during the Import operation). Then Git Repositories UI would be just a view on available repositories in the selected workspace. Some improvements have been made here but we can refine further in M8. I think we made GIT cloning much more friendly now: 1. known hosts are added automatically by confirmation 2. credentials dialog is opened only when authentication is required 3. No need for linking it to a directory any more I'm marking this bug fixed, if anyone has some more usability issues please open individual bugs for them. |