Community
Participate
Working Groups
If we want to self host with Orion, we need to change the way of working with Git repos. The idea of working with Git repos like local file systems is wrong. Especially for a Git user, who knows how to use Git. Moreover doing Git Add, Commit and Push during 'Save' operation does not perform well and does not look good, especially if you look at the commits' history. Ideally, Git commands should be available in Orion toolbars, menus etc. Users should be able to perform commit and push and other Git operations in the navigator. Since we want something quickly, Boris suggested to add a Git command shell that supports the following set of commands: git config (or some other way to set user.name and user.email) git clone <URL> (open question: what about non-public repositories?) git status git checkout git tag (for tagging) git remote (for listing and adding remotes) git fetch git merge git pull git push (also: git push --tags) I think that the set may be smaller. For instance we don't need 'git config' to set user.name and email. We could do it via the user profile. 'git clone' does not have to be called explicitly too. We can just create a top-level folder and link it to a repo what would clone the repo automatically. If we agree to start from simple Git shell, I'll raise separate bugs for server API and UI. I think that APi for Git should be some kind of an extension to our existing file API. If you have other ideas, let's discuss it here.
I would like to help out with this effort. We already have support for a Git CLI within the JGit PGM module.
(In reply to comment #0) > If we agree to start from simple Git shell, I'll raise separate bugs for server > API and UI. I think that APi for Git should be some kind of an extension to our > existing file API. I think it should be separate from the file API. The file API is intended to be very simple file access, similar to what you would get from java.io.File. There may end up being a large number of different "team provider" APIs for Orion so we can't mix it into the base API. I think Git-specific support should be a separate API (although URLs would look similar, replacing "/file/..." with things like "/git/add/...") The advantage of a "shell" is that it gives us a quick way to display the output of git commands like log/status/diff/etc. I'm not liking the idea of a true shell where the user types in commands. Easier for the user would be commands in the Navigator menu, and then a "console" view that shows the result of that command. I find the most painful part of using git command line is typing all the paths when executing the commands, so if we could avoid that without a lot of extra effort it would be good. From a UX perspective it would also force us to deal with the scalability problem of large numbers of navigator commands.
Creating a UI first is always tricky. It's been a year and we still don't have all the workflows perfectly down in EGit land. Getting a quick shell up and running for demo purposes until we have something better seems like a fine route for me. The CLI code we have is in the org.eclipse.jgit.pgm bundle... see org.eclipse.jgit.pgm.Main.run(...)
(In reply to comment #3) > Creating a UI first is always tricky. It's been a year and we still don't have > all the workflows perfectly down in EGit land. We don't want all workflows handled. There are some which seem to be more popular. I would start from these. > Getting a quick shell up and running for demo purposes until we have something > better seems like a fine route for me. Well. We have a demo right now. We don't want co create another one :) I guess Orion devs would like to start self hosting using this simple Git shell as soon as possible. And this is the purpose of the bug.
A good start would be to support all the workflows shown in this screencast in some form: http://www.vimeo.com/16395537
(In reply to comment #0) > git config (or some other way to set user.name and user.email) See bug 337820. > git clone <URL> (open question: what about non-public repositories?) See bug 337818. > git status And git diff - see bug 337212. > git checkout > git tag (for tagging) > git remote (for listing and adding remotes) > git fetch > git merge > git pull > git push (also: git push --tags) No bugs for these commands yet, will probably file them in 0.2M7. See also bug 337463 which added REST API for retrieving file content from index.
We started talking about UI strategies in bug 337867 (which is really about the file action extension) so I'd like to bring the discussion back to this bug. There(In reply to comment #0) > Ideally, Git commands should be available in Orion toolbars, menus etc. Users > should be able to perform commit and push and other Git operations in the > navigator. Since we want something quickly, Boris suggested to add a Git > command shell that supports the following set of commands: <snip> > If you have other ideas, let's discuss it here. I think that some commands make sense in the navigator, and also from the editor itself. If I'm working in a file and realize I've screwed something up, or want to toss my changes, I may want to look at the history of the file or even revert it. These actions make sense from my current context, be it a file in the navigator, or even from the editor itself (replace with committed content from repo). Boris was imagining a separate UI for staging and committing. This is actually how I work today. I use the git command line for pulling, pushing, etc., but when I want to gather what I've done and stage for commit, I prefer a different view of the world. I use the Git Gui which is designed just for this kind of task, and although it's kind of cheesy and has some bugs, it has all the info I want gathered in one place: 1 - what files have I changed? 2 - I click on changes and see the diffs 3 - which changes are staged? 3 - I can stage/unstage, commit, etc. from one place. I find this very convenient. I'll attach a screenshot. So I can imagine that we have: - navigator and editor actions for some things. (Not sure if having push on the navigator makes sense or not. Would I ever want to stage/commit/push one change independently of the other changes I've made? Maybe. It seems potentially dangerous. - a page for staging and committing with a lightweight differ - possibly a merge page with a side by side diff but I would probably go back to the stage/commit page to actually commit the merged work
Created attachment 189541 [details] screenshot of "Git Gui" This UI is nothing to write home about as far as presentation/colors go, but it has all the tasks I need when I'm trying to figure out what changes I've made. I find it interesting to look at a non-eclipse based GUI as a way to look at task organization independent of an IDE.
Copied from a comment on bug 337867: I am trying to get everybody in the same mindset of "page == resource + task", and that we should err on the side of putting functionality on separate web pages instead of adding to existing ones. The default for new UI functionality should always be to think about how we can add a new separate page as opposed to how we can add to an existing page. I agree that we may want to combine functionality later to improve the flow. The key point is that we need to be able to defer decisions about this until later. If you develop it as features that live on a single page, it is going to be really hard to separate the code later. On the other hand, it is usually easy to combine functionality from independently developed components on one page.
(In reply to comment #7) > I think that some commands make sense in the navigator, and also from the editor > itself. Right. We can also add actions to open Git View for staging and committing. More or less what we do for files, we may click them and a new Editor UI is open. > Boris was imagining a separate UI for staging and committing. > This is actually how I work today. I use the git command line for pulling, > pushing, etc., but when I want to gather what I've done and stage for commit, I > prefer a different view of the world. Right we need a separate UI to show Git repositories, for showing Git status doing commit and push. And also a separate piece of UI for showing diffs per file. This is what Libing is doing. > So I can imagine that we have: > - navigator and editor actions for some things. (Not sure if having push on the > navigator makes sense or not. Would I ever want to stage/commit/push one change > independently of the other changes I've made? Maybe. It seems potentially > dangerous. > - a page for staging and committing with a lightweight differ > - possibly a merge page with a side by side diff but I would probably go back to > the stage/commit page to actually commit the merged work I think that the side by side diff should be also a separate UI. Otherwise it would be like having the editor and navigator on the same page, what as I understand, is not something we want at this point.
Created attachment 189750 [details] screenshot of Git Gui with menu showing Thought it might be useful to show the commit menu in git gui. I never use anything but this menu. I've annotated the screenshot with what I think is "p1" behavior for a staging page, and what is "p2"
> (In reply to comment #0) > git checkout > git tag (for tagging) > git remote (for listing and adding remotes) > git fetch > git merge > git pull > git push (also: git push --tags) I've filed bugs for all of these, and set them as blockers to this one. Feel free to comment and those you think we should have first. Setting a priority would be even better.
This is very close in M7, but moving to M8 to complete the final details (see blocking bugs).
Created attachment 195169 [details] mock up This is what I would like the git-status page to look like. Comments welcome!
(In reply to comment #14) > Created attachment 195169 [details] > mock up > > This is what I would like the git-status page to look like. Comments welcome! I like the mock up because as a user I can overview all the git functions without jumping over to different pages. Two things I would like to comment about the details. 1.I think structural compare will come from fetch.Where do we want to put the result ? In the right pane or a new page? My opinion is to open a new page though. 2.In M7 , all the contents in the left pane are rendered in the same single pane , where scroll bar will appear if contents get big. In M8 we may want sub-panes for different areas so that the overall git functions always appear at the bottom.
(In reply to comment #15) > (In reply to comment #14) > > Created attachment 195169 [details] [details] > > mock up > > > > This is what I would like the git-status page to look like. Comments welcome! > > I like the mock up because as a user I can overview all the git functions > without jumping over to different pages. Two things I would like to comment > about the details. > 1.I think structural compare will come from fetch.Where do we want to put the > result ? In the right pane or a new page? My opinion is to open a new page > though. I don't imagine opening a new page on pull, fetch, merge. If the merge has no conflicts, I would imagine that I would just see the new commit entries in the log on this page. (The log would update to show the most recent 5.) If there is a conflict, I would expect to see a prominent notification and link to the structural compare/merge page. > 2.In M7 , all the contents in the left pane are rendered in the same single > pane , where scroll bar will appear if contents get big. In M8 we may want > sub-panes for different areas so that the overall git functions always appear > at the bottom. I wouldn't worry too much about this initially. If the staged or unstaged list is so long that you can't see the other actions, I don't think that's so bad. Typically, you would want to stage/commit those changes (or stash them?) because you won't be able to merge anyway. Incidentally, the mockup doesn't show the existing stage/unstage buttons. Also we talked about a "revert" which replaces the file with the checked out version.
(In reply to comment #16) > Incidentally, the mockup doesn't show the existing stage/unstage buttons. Also > we talked about a "revert" which replaces the file with the checked out > version. Yes, I wanted to add them (and the icons that show the nature of the change for each file) but the prototyping tool didn't let me do that easily. > If there is a conflict, I would expect to see a prominent notification and link > to the structural compare/merge page. I was thinking that the merge case would be supported by the same page (git-status) with additional information at the top that your changes are the result of a merge. Not sure what you were thinking of for a structural compare?
(In reply to comment #17) > I was thinking that the merge case would be supported by the same page > (git-status) with additional information at the top that your changes are the > result of a merge. Not sure what you were thinking of for a structural compare? I think we should give user a link to structural compare page right after fetch and before merge. This is similar to CVS sync. Not sure if git fetch can "predict" conflicts. If there is a conflict , I can open the 3-way compare here .This will be the perfect time for me to resolve the conflict , rather than git merge generating a conflicting file on my local repo. On the other hand , if there is no conflicts , I may still be interested to see the incoming changes from remote. Currently if I use [git][remote][fetch] , I can only see the new commit/commits at the top. In case of multiple incoming commits , I am not interested in seeing details on each commit. All I care is the overall incoming changes since my last pull , which I can't see on git status page.
(In reply to comment #18) > (In reply to comment #17) > > I was thinking that the merge case would be supported by the same page > > (git-status) with additional information at the top that your changes are the > > result of a merge. Not sure what you were thinking of for a structural compare? I was responding to Libing's mention of a structural compare page that appears when you push the pull or merge buttons. That seemed jarring to me, so I was suggesting that if we need to go to a compare page to merge conflicts, we should alert the user and give them a link rather than jump to a new page. > I think we should give user a link to structural compare page right after fetch > and before merge. This is similar to CVS sync. Not sure if git fetch can > "predict" conflicts. > If there is a conflict , I can open the 3-way compare here .This will be the > perfect time for me to resolve the conflict , rather than git merge generating > a conflicting file on my local repo. > On the other hand , if there is no conflicts , I may still be interested to see > the incoming changes from remote. I've heard discussion of this before and seen bugs go by, but I wonder if this will make sense to a "normal" git user (if there is such a thing). If the state of the art is to create the merged "conflicts" file I don't see that we have to be any smarter for the June release.
(In reply to comment #15) > (In reply to comment #14) > > Created attachment 195169 [details] > > mock up > > > > This is what I would like the git-status page to look like. Comments welcome! > > I like the mock up because as a user I can overview all the git functions > without jumping over to different pages. I think we are trying to put too much on one git status page. For instance the "tiny log" will not be very useful as we usually have lots of incoming commits. Personally I like to have log and status on separate pages. Do we plan to show commits from the remote tracking branch in the "tiny log"? If not, the Fetch button should not be on the git status page, since we would not see the result of the fetch operation.
(In reply to comment #20) > I think we are trying to put too much on one git status page. For instance the > "tiny log" will not be very useful as we usually have lots of incoming commits. > Personally I like to have log and status on separate pages. Yes the complete log needs to be on a separate page, but I need to see at least the last commit to decide if I want to check "amend" or not. Showing a few more recent commits seemed to make sense to me. > Do we plan to show commits from the remote tracking branch in the "tiny log"? > If not, the Fetch button should not be on the git status page, since we would > not see the result of the fetch operation. I forgot to add that to the mockup. I would like to see something like the "you are ahead/behind by <n> commits" message from the command-line "git status" on this page. This would show at least an indication of the result of the fetch operation.
Created bug 345978 345980 345981 for corresponding tasks. Simon and I will discuss on implementation details this week end or early next week.
(In reply to comment #22) > Created bug 345978 345980 345981 for corresponding tasks. > Simon and I will discuss on implementation details this week end or early next > week. Created bug 345978 bug 345980 bug 345981 for corresponding tasks. Szymon and I will discuss on implementation details this week end or early next week.
Szymon, you can close this when feature work for 0.2 is done.
As said on the call yesterday (http://wiki.eclipse.org/Orion/Meeting_minutes/20110609) the git feature work is done. We will be opening new bugs and enhancement requests for further work in the area.
