GNOME Bugzilla – Bug 700462
[PATCH] Improvements about the commit history graph
Last modified: 2013-05-17 13:18:50 UTC
The first feature request of [the gitg's wishlist][1] is "Honour commit parent order", this series of patches has fulfilled that wish." Now, it should be much easier to see how the development goes on from the history graph. [1]: https://live.gnome.org/Gitg/Wishlist * Repect the mainline of merges * Use the same color for every long-runing lane
Created attachment 244410 [details] [review] Repect the mainline of merges
Created attachment 244411 [details] [review] Use the same color for every long-runing lane
Review of attachment 244410 [details] [review]: Initial comments, please respect coding style if () { } else { }
This is still a
This is still a trivial change, after testing some repo, it does not always show what I expected, I will keep working on it.
Created attachment 244444 [details] [review] Repect the mainline of the merges Normally the 1st parent of a commit is the branch we're merging _into_, so if you keep this on the left then you can always read a merge as right-to-left. Previous it seems to be a bit random. By introducing an auto-increased id to every lane, the earier a lane is created, the more priority it has.
Created attachment 244445 [details] [review] Use the same color for every long-runing lane
Okay, I have revised the both patches, it should be good to go now. All the repositories I have tested so far, the history graph was rendered as expected.
Created attachment 244447 [details] [review] Repect the mainline of the merges(fixed tab indentation)
Created attachment 244448 [details] [review] Use the same color for every long-runing lane(fixed indentation)
Third version, fixed tab indentations.
Created attachment 244449 [details] [review] Coding style fix
Created attachment 244450 [details] [review] Repect the mainline of the merges(coding stayle fix)
Created attachment 244452 [details] [review] 0001 - Repect the mainline of the merges(coding stayle fix)
Created attachment 244453 [details] [review] 0001 - Repect the mainline of the merges(coding style fix)
Created attachment 244454 [details] [review] 0002 - Use the same color for every long-runing lane(coding style fix)
Okay, the submitting process is a hell. Now, it's good to go.
Created attachment 244455 [details] [review] 0001 - Repect the mainline of the merges (typo fix)
Created attachment 244456 [details] [review] 0001 - Respect the mainline of the merges (typo fix)
Created attachment 244459 [details] [review] 0002 - Use the same color for every long-runing lane (typo fix)
Review of attachment 244456 [details] [review]: See comments inline. Also I would like to ask you for a screenshot or something showing the difference between what we have and using your patch, since it is not easy to realize what we are reviewing here :) ::: libgitg/gitg-lanes.vala @@ +28,3 @@ public bool inactive_enabled { get; set; } + // last assigned lane id If you need a comment it means that the name is not good. what about, d_lane_id ? @@ +37,3 @@ class LaneContainer { + // a unnique id to identify the lane, the later the lane this comment does not seem very correct. the id is contained by the LaneContainer while in the comment you point that the id points to the specific lane @@ +129,3 @@ // there is no lane reserver for this comit, add a new lane + LaneContainer newlane = new LaneContainer(myoid, null); + // we are creating a new lane, assign the id no need for this comment, the previous one already points there is a new lane @@ +214,2 @@ newlane.lane.from.prepend(pos); + // we are creating a new lane, assign the id same here, remove the comment.
Created attachment 244488 [details] Screenshots before the patch As you can see, the order of master branch, gitg-0.2 branch and progress branch is random.
Created attachment 244489 [details] Screenshots after the patch As you can see, the master branch(mainline) is always displayed first.
Okay, take Gitg's repo as an example, here are the screenshots. Also notice that in the second screenshot, the mainline lane of the development is displayed in the same color across the merge, this makes it easier to keep track of the evolvement of the project. You can apply the patch, and try it with your other repositories and see how it is improved.
Created attachment 244508 [details] [review] 0001 - Respect the mainline of the merges (Revised version)
Created attachment 244509 [details] [review] 0002 - Use the same color for every long-runing lane (Revised version)
Review of attachment 244508 [details] [review]: Commit message does not look like what it introduces the patch anymore...
Review of attachment 244508 [details] [review]: It turns out that introducing an id for each lane is not necessary, the existing 'pos' variable serves the same purpose.
Created attachment 244510 [details] [review] 0001 - Respect the mainline of the merges (fixed commit message)
Created attachment 244511 [details] [review] 0002 - Use the same color for every long-runing lane (fixed commit message)
Review of attachment 244510 [details] [review]: Patch looks good to me.
Review of attachment 244511 [details] [review]: I guess it is fine.... :)
Comment on attachment 244510 [details] [review] 0001 - Respect the mainline of the merges (fixed commit message) Thanks
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
This is great, thanks.
Are you missing anything else to submit to this bug report?
https://live.gnome.org/Gitg/Wishlist might need to be updated. And, Do I need to port the patch to gitg-2 branch?
not really, we are not making more releases for 0.2 unless there is a build break. I'm marking this then as fixed. Thanks for the patches.
BTW in case that you want to join development you can usually find us in the gimpnet irc in the #gitg channel.
> not really, we are not making more releases for 0.2 unless there is a build > break. I'm marking this then as fixed. Thanks for the patches. Okay, then. > BTW in case that you want to join development you can usually find us in the > gimpnet irc in the #gitg channel. That's great, I'd love to, I just started doing some gnome development mainly driven by improving this app, becasue I rely on it a lot. There is also some question about the gtk+ I need answers, the IRC is really great.
Added to wiki page in edit https://live.gnome.org/action/info/Gitg/Wishlist?action=diff&rev2=13&rev1=12 Thanks.