• Icon: Suggestion Suggestion
    • Resolution: Duplicate
    • None
    • None
    • None
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      When you are about to add files to the next commit, you have the staged files in the top and unstaged files in the bottom. Whenever you add a file of the unstaged files or remove on from the staged files, both file lists are freshed. Now the annoying thing happens, when either of this list is longer than the height of the subwindow so you have to scroll down.

      Whenever you want to add or remove several files one after another which you only reach in the list after scrolling down, you have to scroll down again after each refresh and find the location where you left of. Sometimes SourceTree keeps the scroll position, but mostly it looses it and refreshing sometimes takes several seconds.

      And to make it worse, when you scrolled down after the first refresh, sometimes a second refresh occurs and not only that you loose the position again, often the click on one file is happening on the file at the position of the mouse cursor after the fresh, ie. a completely different file. Then you have to remove it from the unstaged files again which causes additional work.

      So it would be great, if SourceTree would at remember the approximate position within the file lists.

            [SRCTREE-3089] Keep original scroll location in unstaged files

            Please use ticket SRCTREE-4184 , for tracking updates

            Oleksii Nikitenko (Inactive) added a comment - Please use ticket  SRCTREE-4184  , for tracking updates

            +1 for this

            yjutard (Inactive) added a comment - +1 for this

            abd3 added a comment -

            Not all of these issues may be perfect duplicates, but they are roughly similar. There are 10+ issues related to scrolling that are all marked as "low priority". Perhaps someone from Atlassian can merge these issues and their votes to make it more clear that there is a lot of demand for fixing the issue of the scroll/view being reset continuously.

            abd3 added a comment - Not all of these issues may be perfect duplicates, but they are roughly similar. There are 10+ issues related to scrolling that are all marked as "low priority". Perhaps someone from Atlassian can merge these issues and their votes to make it more clear that there is a lot of demand for fixing the issue of the scroll/view being reset continuously.

            abd3 added a comment -

            There are lots of similar issues related to scrolling on this board. One suggestion at a minimum:

            Sourcetree will keep a selected file in view in the scroll window, as long as it's in the same folder as the file you last staged (kind of weird behavior). After you stage a particular file, Sourcetree could at least select the next file in the list so that file stays within view in the window.

            abd3 added a comment - There are lots of similar issues related to scrolling on this board. One suggestion at a minimum: Sourcetree will keep a selected file in view in the scroll window, as long as it's in the same folder as the file you last staged (kind of weird behavior). After you stage a particular file, Sourcetree could at least select the next file in the list so that file stays within view in the window.

              Unassigned Unassigned
              94f2816de97d martenlehmann
              Votes:
              8 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: