Community
Participate
Working Groups
In response to bug 336116 , we need to integrate git log and remote functions in the git status page. We may need the git log and remote page to behave more like a widget so that : 1. The tiny log in the status page can be configured to be a subset of the log result. 2. The fetch and merge result cab be rendered in a DIV of the status page.
*** Bug 342210 has been marked as a duplicate of this bug. ***
reminder that anywhere we show the log subset we want to link to the page that shows everything. This is shown in Boris' mockup in https://bugs.eclipse.org/bugs/attachment.cgi?id=195169 but I was afraid this detail might get lost.
I've finished bug 347079 , restructured the git status page so that : 1.All actions is running git commands. 2.Different zones (stage , unstage ,commit) run their own renderers. 3.Actions that are global to different zones go to page action. 4.Progress service reacts to all commands. Targeted the integration to RC1 , which is the only week we can add features. In general we can just add two zones in the status page so that 1.Log zone(bug 345980) just needs a div to render the log subset and a link to the full page. 2.Remote zone(bug 345981) needs a div to render all command buttons(fetch , merge , pull,push ,etc) 3.We also want git status REST API to return the URI of git log and remote , where user came to status page. Szymon/Tomasz : what's your vision and thoughts on this ?
(In reply to comment #3) > Szymon/Tomasz : what's your vision and thoughts on this ? I thought this feature was deferred. I'll check tomorrow how much time is needed to fix bug 345980 and bug 345981 and let you know.
Would having an action for reseting to a given remote branch (bug 347951) be part of the client changes here? Or is there a different bug for it? Where would you like to have the action? Git Status page is one place, but it could be also available on Git Repositories page, after you drilled down to remote branches.
(In reply to comment #5) > Would having an action for reseting to a given remote branch (bug 347951) be > part of the client changes here? Or is there a different bug for it? bug 347951 addresses this. > where would you like to have the action? Git Status page is one place, Bug 343961 puts a "reset --hard HEAD" action at page action level , as that applies to both unstaged and staged files. If bug 347951 will flush both unstaged and staged files as well then I think the action will be the same level. > but it could be also available on Git Repositories page, after you drilled down to remote branches. We can make the command generic so Git Repositories page can just use it , if it is needed.
Created attachment 197509 [details] EGit Stage view I've just talked to Libing trying to understand why he needs RemoteLoction on Git Status page (bug 348558). He showed me Boris' mock up, which for me looked like status page on steroids. I know it's a little late for comments like this, but IMHO we should keep the page simple just like EGit guys did with their Git Staging view (attachment).
(In reply to comment #7) > Created attachment 197509 [details] > EGit Stage view > > I've just talked to Libing trying to understand why he needs RemoteLoction on > Git Status page (bug 348558). He showed me Boris' mock up, which for me looked > like status page on steroids. I know it's a little late for comments like this, > but IMHO we should keep the page simple just like EGit guys did with their Git > Staging view (attachment). See also my comment on Bug 336116, comment 20. I agree with Tomasz and it is not too late, since the mini git log and the panel with fetch, push actions is not added yet. I think we agreed some time ago to keep pages simple and Git Status UI (with the log and remote actions) is not following the rule IMO. BTW, I wonder how Git Status UI would look like on a mobile device with 5 inch screen.
The difference between Orion and EGit is that with EGit, you have multiple views and/or editors open at the same time. Our current workflow doesn't "flow", there are too many separate pages I have to use to do a simple change. I can do my local commit on the status page, then I need to go somewhere else (and drill down a tree) to push my change. Most likely, I will also have to do a pull first, another thing that would have made a lot of sense from the git status page.
(In reply to comment #9) > The difference between Orion and EGit is that with EGit, you have multiple > views and/or editors open at the same time. > > Our current workflow doesn't "flow", there are too many separate pages I have > to use to do a simple change. I can do my local commit on the status page, then > I need to go somewhere else (and drill down a tree) to push my change. Most > likely, I will also have to do a pull first, another thing that would have made > a lot of sense from the git status page. Regarding git, there are three pages now. Git Status, Git Log (I would expect to merge git log and remote soon) and Git Repos. So to work with Git, you actually need two pages open (Git Repos is not used that often). What we really miss is a mechanism to refresh pages when changes occurrs on the server. Then when I switch between pages, changes would be refreshed automatically. Moreover you could open pages in separate views in Eclipse (I guess). Then I would have Git status and Git Log opened next to each other. Maybe in the nearest future web browsers would also give a way to open tabs next to each other.
(In reply to comment #9) > Our current workflow doesn't "flow", there are too many separate pages I have to > use to do a simple change. Agree, but navigation between different git pages is going to be more intuitive once bug 343542 is fixed.
(In reply to comment #9) > The difference between Orion and EGit is that with EGit, you have multiple > views and/or editors open at the same time. Agree. We are struggling with task granularity for these web workflows. I think the granularity of an eclipse desktop view is smaller than a web workflow. We know we can't manage as many browser tabs as we do number of eclipse views required to get work done. > Our current workflow doesn't "flow", there are too many separate pages I have > to use to do a simple change. I can do my local commit on the status page, then > I need to go somewhere else (and drill down a tree) to push my change. Most > likely, I will also have to do a pull first, another thing that would have made > a lot of sense from the git status page. To expand on what Boris is saying. What I find the most annoying about the current workflow is the fact that git status and the rest feel like two completely separate worlds. So I've just looked at all my changes, done some commits, feeling good, now I want to push. The only way to get quickly(?) to do a push is to choose the "Repositories" link, drill way down into a tree (that doesn't remember its last expand state), and then do "blind" pushes and pulls (no view of incoming/outgoing), or else select git log. And if I do a "blind" push and get an error, now I have to go to remote and figure out what's coming in. I am a fan of Git Gui which lets me stage + push + fetch/merge. Here is a "middle ground" proposal (since we are in feature freeze and unfortunately still debating workflows.) - fix the log page (bug 344500) so that I can switch quickly (without a full page reload) between remote (incoming) and local (outgoing) changes. - Add a prominent link on git-status that says "Push" and leads to the log on local branch. Then at least my workflow is - do my commits - one link leads me to outgoing changes and push - i can push or if i'm curious, i can first quickly look at remote and pull first
my comment mid-air collided with Szymon and Tomasz. I think that fixing bug 344500 and 343542 will go along way here. Most important to me are the way these other bugs are addressed. For bug 344500 it needs to be very simple and fast to switch between local and remote tracking so that I can sort out incoming/outgoing For bug 343542, the link needs to be task-based "Push my work" or whatever. A list of "related links" that just tell me the names of pages will be less helpful, that means I still have to think about the page structure rather than just do my work.
fixed with 00e242e86764ec5dfe4e0c49a751c87a97bc6dfb. Code reviewed by Boris. Now in git status page , if your repo is cloned by Orion , you can: 1.See a mini log with 5 recent commits on your branch. 2.There is a link , e.g. "master" , showing as the mini log's title.Clicking on this link brings you to the full log page on your branch. 3.See a mini log for your remote. 4.There is a link , e.g. "origin/master" , showing as the mini log's title.Clicking on this link brings you to the full log page on your remote. There are two things left : 1.The mini log for remote does not show 5 lines. I will open a bug for this. 2.bug 339558. I will fix this in RC1.
