Bugzilla – Full Text Bug Listing
| Summary: | [client] Add UI for Push, Fetch and Merge | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Szymon Brandys <Szymon.Brandys> | ||||
| Component: | Client | Assignee: | Szymon Brandys <Szymon.Brandys> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | bokowski, john.arthorne, libingw, malgorzata.tomczyk, susan, tomasz.zarna | ||||
| Version: | 0.2 | ||||||
| Target Milestone: | 0.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 334120, 339111, 339115, 342575, 342731, 342736, 342844, 343151, 343240 | ||||||
| Bug Blocks: | 336116 | ||||||
| Attachments: |
|
||||||
|
Description
Szymon Brandys
How do you imagine this UI to look like? Do you have a rough sketch or could produce one? (ASCII art or hand-drawn would be appropriate) We may also want to think about making the UIs (exisitng and future) handle server response generically by services. So the GIT implementation is just one of the service providers. I don't believe the Git UI should be used for other SCM systems, other than reusing common components like the compare viewer/editor. *** Bug 339564 has been marked as a duplicate of this bug. *** Hi ,Szymon , do you have any insight on how pull will detect a conflict? Boris and I sat down together and played around with test case 1 in the description of bug 342044. Regarding the temporary file generated by git pull in case of merge , with content shown as below: line one <<<<<<< HEAD line two by repo2 ======= line two by repo1 >>>>>>> 3cb9a690f9f6f9d95ee979045ffd4d48f7a0237c line three line four The default git/diff will just use the file as it is to compare against index. Although there is information in the diff indicating what has been changed on both side against the common ancestor , it is not user friendly. If there are complicated conflicts , user will have no idea how to merge. We considered that a better approach is to provide a 3-way compare editor , where user can understand easily why the conflicts happened. In the example above , one of the possible the 3-way compare editor layout would be : 1.LEFT : An editor representing HEAD. 2.RIGHT : A viewer representing 3cb9a690f9f6f9d95ee979045ffd4d48f7a0237c. 3.MIDDLE : A viewer representing the common ancestor. In order to achieve this , we may want server side to support something like /git/3way-diff/diffURI. The response will provide (by the example above): 3 fileURIs representing the 3 files. diff : HEAD VS common ancestor diff : 3cb9a690f9f6f9d95ee979045ffd4d48f7a0237c VS common ancestor. Szymon/Tomasz/John : Please provide your comments , once we have a solid agreement and prototype of server support , I will start some JS unit tests. I think that a natural way of resolving conflicts for Git users is to just open unresolved conflicts in an editor, resolve them there, then add and commit. Why can't we address it first. It is small, but good enough before we start working on 3-way compare. I wonder if we could add markers showing conflicts in our editor? Boris, during our offline conversation I was referring to Bug 339045: Had a conversation with Szymon today. The work flow he suggested is : 1. you have Navigator UI, Status UI, Push/Pull UI 2. you do changes in Navigator UI, then go to Status UI to stage changes and commit 3. then go to Push/Pull UI to push them 4. now, you use Pull on the Push/Pull UI 5. some changes are automatically merged, some need your attention 6. files that need a merge should be flagged somehow, so when go back to Navigator UI, we can find them and merge manually 7. when we do this, we go back to Status UI, and we know which files need a manual merge. 8. do manual merge by 3-way editor (UI design not yet determined) 9 . we stage merged files and we are done. I will draw a picture for 3, 4. But basically it will just show a list of commits local vs remote. So the UI will be similar to the Log UI and actions available in the toolbar will be fetch and merge. Created attachment 192933 [details]
Illustration
The illustration shows only Fetch and Merge actions. We could use the left side of the UI for commits to Push and the UI could be used for pushing changes. However Fetch/Merge UI works with a a remote branch while Push UI works with a local branch. Since these are two different resource types, I would suggest to have two different UI for these operations. (In reply to comment #7) > I think that a natural way of resolving conflicts for Git users is to just open > unresolved conflicts in an editor, resolve them there, then add and commit. Why > can't we address it first. It is small, but good enough before we start working > on 3-way compare. +1 from me. I'm fine with resolving merge conflicts in a regular editor as well. This is how I work with git/Egit right now. Adding Susan for comments about UI. I talked to Szymon today, here are some notes: I would suggest adding the merge/fetch/push/pull functionality to the git-log page. Let's look at an example. I have the master branch checked out, and it has an associated remote tracking branch origin/master. I also have a local branch called "bugfix". As a result, I would expect to have three pages I can go to. git-log.html#master, git-log.html#bugfix, and git-log.html#origin/master. (initial explanation without push/pull:) On git-log.html#master, I would see that this is my checked out branch, and there would be a button "Merge from" and next to it a dropdown with all branches, with origin/master preselected. I would also need a link to git-log.html#origin/master so that I can look at that branch. On git-log.html#origin/master, I would have a button "Fetch" to fetch the latest from my remote repository. On git-log.html#bugfix, I would see a button "Check out" or an explanation that I cannot check out since I have changes in my working directory. If I click on "Merge from" on git-log.html#master with origin/master selected in the drop down, I would see new commits at the top of my list. If the merge couldn't be done automatically, I would see that I have changes that need to be resolved, with a link to git-status.html so that I can see what needs to be done. Now to add push and pull: Push would make sense to me on every page that shows a remote tracking branch, or a local branch with an associated remote tracking branch. Pull would only make sense on a local branch that is checked out, like "merge from". One more thing, not top priority: When you are on a local branch with an associated remote tracking branch, you would want to see some information on how your current state relates to the remote tracking branch. Same if you see the remote tracking branch and there is an associated local branch. For example, highlight the commit that the other branch points at, if the other branch is behind the current branch you are looking at. If the other branch is ahead, you could display a message, something link "origin/master is ahead by six commits". (In reply to comment #12) > Adding Susan for comments about UI. I'm not sure I follow the latest discussion (a picture would help!). I think we should focus on the simple case first, which is push and pull. (In reply to comment #13) > > Now to add push and pull: Push would make sense to me on every page that shows > a remote tracking branch, or a local branch with an associated remote tracking > branch. I agree that we see push on a local branch with associated remote tracking branch. Not sure about push on a remote tracking branch. Would we only show this if we detect that there are local changes? Seems like before I push I would want to be able to understand what the changes were. (Mentioned below I realize) > Pull would only make sense on a local branch that is checked out, like > "merge from". Agree. > > One more thing, not top priority: When you are on a local branch with an > associated remote tracking branch, you would want to see some information on > how your current state relates to the remote tracking branch. Same if you see > the remote tracking branch and there is an associated local branch. For > example, highlight the commit that the other branch points at, if the other > branch is behind the current branch you are looking at. If the other branch is > ahead, you could display a message, something link "origin/master is ahead by > six commits". Even some very raw presentation of this info is important. Without it, I think that push and pull would feel "blind." (In reply to comment #14) > (In reply to comment #12) > > Adding Susan for comments about UI. > > I'm not sure I follow the latest discussion (a picture would help!). There is a picture attached ;) (In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #12) > > > Adding Susan for comments about UI. > > > > I'm not sure I follow the latest discussion (a picture would help!). > > There is a picture attached ;) I saw that one, but then there was further discussion about using the existing git log page, and where push and pull would appear. I guess I was asking Boris for a picture of his comment 13. I use push/pull every day in my workflows. Merge and fetch are rarely needed by me (wait til we have a maintenance branch!) so having a dedicated fetch/merge UI is less meaningful to me at the moment. If I am looking at my local branch, I would expect to see some status text somewhere that tells me if I have commits to push, and there would be a "push" button there. If I'm looking at my remote branch and I am behind, I would see some text and a "pull" button. I can reload that page whenever I want to see where I stand. In the long run, it would be kind of cool to see an arrow that showed me where I stand relative to the remote commits. "You are here". UI for Fetch, Merge is done. The current shape of bug 339115 lets me continue working on Push UI. The UI is in place. New bugs should be raised for further work. |