| Git Staging view enhancements to contribute [message #1053819] |
Tue, 07 May 2013 17:21  |
 Steve Elsemore
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Hello,
My company, CollabNet, recently released a free graphical client for Git that is based on Eclipse and eGit (as well as our own desktop plugins), but is packaged as an RCP application and is relatively lightweight (does not include Eclipse IDE plugins, and is not intended to be an IDE). You can go to http://www.collab.net/giteyeapp to read more or to try it out, but I'm not mentioning this in order to promote this app - I'm mentioning it in order to provide some background into how it came to be that we are now looking to contribute a number of enhancements back to eGit, particularly to the Git Staging view.
When we put together this application, we spun off our own view based on the Git Staging view, with these being the main differences:
1. The files (staged and unstaged) can be shown using the chosen presentation - "Flat" (same as current presentation), "Tree" or "Compressed".
2. The buttons that are specifically related to commit ("Amend Previous Commit", "Add Signed-off-by", "Add Change-Id") were moved from the view toolbar to the header of the "Commit Message" section. We did this because it seemed to make more sense, but also to free up some space in the view toolbar for the next enhancement.
3. Added a "Find" widget to the view toolbar (typing here filters the files that are shown in staged/unstaged sections).
4. Enhanced the context menu for the staged/unstaged sections to enable a more robust set of options.
5. Turned the right side of the view into a vertical sash form with the current Commit Message section on top, and a new tabbed section on the bottom.
6. One of the tabs in this new bottom section is called "Diff". That tab simply shows the diff for whatever file is selected in the staged or unstaged section.
7. The other tab in the new bottom section is called "Tasks". This tab provides enhanced Mylyn integration. It includes a dropdown from which a Mylyn task query can be selected, and shows the tasks from the selected query. Tasks can be dragged and dropped to the Commit Message area (or context menu option can be used) to add the task info to the commit message.
8. Possibly the biggest change we made, and one that the eGit community perhaps will not want to see in the Git Staging view, is this last one. Because our application is not intended to be an IDE, it does not include any of the resource explorer views. Partly for that reason, we decided we should make our version of the Git Staging view move flexible in what it can be used for. We renamed our view "Git Files", and we changed the text for the top left section from "Unstaged Changes" to "Working Tree Files". Then we added a dropdown to the header of this section that controls which files are shown. The default is "Show Pending", which results in the same behavior as the current Git Staging view. But you can also choose from "Show Conflicts", "Show Untracked", "Show Ignored", "Show Clean", "Show Modified", "Show All". Combined with the Find feature (#3), this provides a way to locate and work with any file in the working tree. Note that the bottom section still shows staged changes only.
So, as I mentioned, I would now like to start contributing back any of these changes that the community considers desirable. I've read the EGit Contributor guide and familiarized myself with how to contribute changes to EGit, and recently contributed a very small fix to the Git Repositories view, just to get my feet wet. But rather than just starting to throw out patches for these changes, I figured it would be good to get some feedback first. Are there any of these changes that should not be made to the Git Staging view for any reason? Any warnings or suggestions about how the changes should be implemented? If I was to do these changes, I would plan to contribute each enhancement separately, probably in more or less the order that I listed them above. Some of them obviously require a lot more consideration than others. For example, in our application, we bundled the Mylyn plugins needed for the enhanced Mylyn integration (#7), so we could more or less "hard-code" this feature. But in eGit this enhancement might require a new extension point or something so that the feature could be included when Mylyn is installed, but would not make eGit dependent on Mylyn.
Anyways, looking forward to feedback and ideas. I've attached a few screenshots of our customized "Git Staging" view.
Thanks,
Steve
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03326 seconds
] 
Search
Help
Register
Login
Home
