-
Notifications
You must be signed in to change notification settings - Fork 267
Show the list of children in the commit details #710
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show the list of children in the commit details #710
Conversation
96cf2b6 to
c0eba51
Compare
@love-linger, just wanted to ask for your feedback. Is this still not good enough in your opinion? Or do you have some other concerns?
I am currently testing this PR. And is reviewing the GIT documentation to see if there is a more efficient way.
Here, I need to clarify that I have never seen this feature in any other Git clients. I have not encountered corresponding requirements in my own use.
-
I really didn't expect this to happen.
截图20241119160446 -
I recommanded you using
FiltersandCheck refs that contains this commitinstead.
To the second point: Filters are already used. I considered doing Check refs that contains this commit, but it would walk the tree another time, so the end result will be slower. I can give it a shot though.
I'll check the first point, I didn't see such things happening in my testing.
If you really need this feature, I suggest you implement it in another way since it is not commonly used.
For example: like Check refs that contains this commit function, add a button after the commit's SHA.
When user clicks it, a popup will show the direct children of that commit.
Useful for navigation between the commits.
You see, the point is to be able to navigate relatively quickly up and down the branch. This is something I normally do several times a day, and it was the reason I've used gitk, and is the reason why I still use it despite this project being so incredibly better in so many ways.
Would you accept this change with either repo or project configuration option to show the children? If the option is unset, the command is not run, the list is not populated, and no UIThread callback happens. The view would not need any changes compared to what was already done, the widgets in the grid raw would just remain constantly hidden.
P.S.: I've checked the image, and either I don't understand your point or everything is actually fine. This commit just has all those children.
The first commit is always the immediate child, so take only 40 initial characters of the line
c0eba51 to
e8c8ac5
Compare
I actually went ahead and added a preference. I've also tried checking refs containing the comment, but that makes the operation significantly slower indeed. I've also made the lists of parents and children scrollable. And I've fixed an issue that I've introduced in this iteration which broke navigation the child when it is clicked in some cases.
Now, if it has to be a button, I suppose I can live with the button as well. Still, inline list is much more useful to me, so I still want you to consider this option.
cc5bb5f
into
sourcegit-scm:develop
* SourceGit.Commands.* should not reference SourceGit.ViewModels.* * remove unused namespace using * update translations for zh_CN and zh_TW * use WrapPanel instead of inner ScrollViewer * some other UI/UX changes Signed-off-by: leo <longshuang@msn.cn>
I have merged this PR and made some modifications:
- Since the entire commit details panel already uses
ScrollViewer,WrapPannelis used to display CHILDREN, as shown in the figure:
image - Modified
Commands.QueryCommitChildrenbased on the code style in the project - Other UI/UX modifications
Signed-off-by: leo <longshuang@msn.cn>
Uh oh!
There was an error while loading. Please reload this page.
This is an updated version of a previously merged and reverted #673.
The general case remains almost as slow as it was, with the following optimizations:
Additionally, the git command now respects:
Preference.Instance.MaxHistoryCommits. This might provide a positive impact in cases when not all of the common ancestors made it to the graph, which in practice should not be the case.I don't see any further optimization opportunities.
That said, I've tried to address the performance problem by loading children asynchronously. In the repos that I commonly use this produces no effect whatsoever as the children are found before the view is actually drawn. I don't have access to the
UnrealEnginerepo, so I used Torvalds' Linux tree as my test stand, and indeed for the commits that are further up the tree the commit details get drawn first without children, and then shortly children blink into the view; the further I go down the tree, the longer it takes for the commit details to get rendered, so that at some point children tasks starts producing results before the view is rendered. In my testing I only saw times above 0.5 seconds when GC was running; though performance issues are IO-bound in this case, so I am not sure whether this figure is representative.TL;DR: in my testing this iteration is usable with big repos.