I often commit just a part of my changes. Since the diffs section in the Summary tab keeps the same scroll position after the commit action, I sometimes end up seeing no changes remaining, until I scroll to the top. This feels counterintuitive as it shouldn’t be possible to be in an impossible scroll position. This might not be crystal clear, so here’s a step-by-step guide:
Do a big change (like adding or deleting 40 lines) to a file called a
Do a big change to another file called b
Do a small change to a file called c
Make sure all diffs are expanded
Scroll to the bottom of the tab so that you see the Staged files section
Stage both visible files starting from the bottom (the point is to end up in a state where a is completely invisible without scrolling)
Enter a commit message and commit
The tab appears empty, as if there were no changes remaining. Scroll to the top and you see the file with remaining changes. (Now obviously you cannot scroll back to the previous position, since it was an impossible position, after staging and committing the files)
The issue is actually also present before committing (see third screenshot below).
Preferred solution
I think at all stages of the staging/committing process, scroll position should be monitored so that we never stay in an impossible position.
Alternatives
An alternative would be to have a clear visual indicator of the presence of stuff before or after the current scroll position. Currently, since the scroll bar disappears when we don’t use it, I cannot know if there is something else just by looking at the screen.
Problem description
I often commit just a part of my changes. Since the diffs section in the Summary tab keeps the same scroll position after the commit action, I sometimes end up seeing no changes remaining, until I scroll to the top. This feels counterintuitive as it shouldn’t be possible to be in an impossible scroll position. This might not be crystal clear, so here’s a step-by-step guide:
abcais completely invisible without scrolling)The issue is actually also present before committing (see third screenshot below).
Preferred solution
I think at all stages of the staging/committing process, scroll position should be monitored so that we never stay in an impossible position.
Alternatives
An alternative would be to have a clear visual indicator of the presence of stuff before or after the current scroll position. Currently, since the scroll bar disappears when we don’t use it, I cannot know if there is something else just by looking at the screen.
Screenshots
After the commit:
Scrolled back to top:
Similar issue after staging, before committing: