The best-case scenario for software development would be to work on one thing at a time, committing each change as you go. In the real world, however, things don't always work like that.
Quinn discovered that while attempting to make some network code changes, the current UI setup didn't have anywhere to display the network status. Being easily distracted, he decided to quickly create a status bar, and ended up tweaking some other parts of the UI too, before getting back to his network coding task. Before he even realized he'd gotten distracted, he had edited half the files in the project! Or so it felt when he saw the huge list in the commit window. Which file affects which task?
If Quinn was working on tasks which affected separate files, then he could group the files into changelists, separating those changelists according to task. This makes it easy for him to see what he is doing. He can commit the files related to UI changes by selecting the files in that changelist...