Community
Participate
Working Groups
Feature request: I believe it would improve usability if the branch graph were given it's own column and was enhanced to show branch information like so: o | o |\ | o |/ o | o |\ | o | |\ | | o | |/ | o |/ o | o
I do not yet understand your proposal, where is the branch information in your picture ?
Created attachment 207986 [details] Screenshot of the revision graph used by the Bizarre version control system.
Bizarre has an excellent, and very simple, revision graph (see attachment). At just a glance, the user can see when a file was branched and merged etc. I believe something like this would add hugely to the usability of egit.
(In reply to comment #3) > Bizarre has an excellent, and very simple, revision graph (see attachment). At > just a glance, the user can see when a file was branched and merged etc. I > believe something like this would add hugely to the usability of egit. How does this relate to your above proposal to have a separate column for a branch graph ? I don't get what a branch graph is and what should be in the other columns ? I couldn't find a version control system named Bizarre. Could you point out what you would like to add compared to the current EGit history view ?
Created attachment 208056 [details] Mockup of a Revision Graph in the History View
See the Revision Graph Mockup attached: The two main points are: 1) The graph is in it's own column. 2) It shows graphically what branch a commit was made on.
So does a5ffbd have two parent commits since it is a merge commit of a1a22 and a1640?
(In reply to comment #4) > I don't get what a branch graph is and what should be in the other columns ? I'm referring to a visual representation of the history of a file. This is one of the most used standard features of most revision control systems including CVS, SVN, Bzr and Clearcase. > I couldn't find a version control system named Bizarre. Apologies, that was a spelling mistake. I meant bazaar (http://bazaar.canonical.com) > > Could you point out what you would like to add compared to the current EGit > history view ? See attachment 208056 [details]
(In reply to comment #7) > So does a5ffbd have two parent commits since it is a merge commit of a1a22 and > a1640? I'm not 100% sure I understand your terminology here but I think the answer is yes. Basically, the grey dots are the mainline/trunk. Then a branch is created. The green dots are commits on the new branch. The new branch is then merged back into the mainline.
What you say is already rendered correctly in EGit as long as you introduce a merge commit that merges the two branches.
(In reply to comment #6) > See the Revision Graph Mockup attached: > > The two main points are: > 1) The graph is in it's own column. This should be simple to achieve but I don't see what would be the advantage of doing that. > 2) It shows graphically what branch a commit was made on. This is not always possible as only the git reflog has this information. Depending on your configuration settings this might get purged by git gc. To enable that we would need to integrate reflog information into the history view.
(In reply to comment #11) > (In reply to comment #6) > > See the Revision Graph Mockup attached: > > > > The two main points are: > > 1) The graph is in it's own column. > > This should be simple to achieve but I don't see what would be the advantage > of doing that. Have a quick look at this bug: 339796 If this enhancement is made, and it becomes possible to reorder columns and hide them etc, it will be important that each field has it's own column. > > > 2) It shows graphically what branch a commit was made on. > > This is not always possible as only the git reflog has this information. > Depending on your configuration settings this might get purged by git gc. > To enable that we would need to integrate reflog information into the history > view. I am not very strong on the internal workings of git and don't know what this would involve. However, coming from a background with SVN, CVS and Clearcase, I have found the lack of a detailed history graph a significant weakness and a barrier to switching to git and convincing others to switch to git. If integrating reflog into History View is a significant problem, a possible alternative would be to make a separate new "Graph Command" and "Graph View". It might be a good idea at this point to split these two issues into two separate bugs? (I probably should have done this from the start)
