Hi Jonathan, On 01/12/19 02:28AM, Jonathan Gilbert via GitGitGadget wrote: > My development environment sometimes makes automatic changes that I don't > want to keep. In some cases, this involves new files being added that I > don't want to commit or keep (but I also don't want to outright .gitignore > forever). I have typically had to explicitly delete those files externally > to Git Gui, which is a context switch to a manual operation, and I want to > be able to just select those newly-created untracked files in the UI and > "revert" them into oblivion. > > This change updates the revert_helper proc to check for untracked files as > well as changes, and then changes to be reverted and untracked files are > handled by independent blocks of code. The user is prompted independently > for untracked files, since the underlying action is fundamentally different > (rm -f). If after deleting untracked files, the directory containing them > becomes empty, then the directory is removed as well. A new proc > delete_files takes care of actually deleting the files, using the Tcler's > Wiki recommended approach for keeping the UI responsive. > > Since the checkout_index and delete_files calls are both asynchronous and > could potentially complete in any order, a "chord" is used to coordinate > unlocking the index and returning the UI to a usable state only after both > operations are complete. > > Since the checkout_index and delete_files calls are both asynchronous and > overlap, they clash in wanting to update the status bar. To address this, > the status bar is reworked so that when an operation wants to display > ongoing updates/progress, it explicitly starts an "operation", which is > tracked by its own object, and the status bar handles multiple concurrent > operations by merging their progress and concatenating their text. This is > captured in a separate commit, since it touches a variety of files. > > The _close_updateindex proc contains error handling (added in d4e890e5) that > has the potential to interact badly with unlock_index running at the > completion of an async operation. I have refactored the procedure into > separate procs _close_updateindex and rescan_on_error. Call sites that > exercised the combined functionality also unlocked the index, so a combined > proc close_and_unlock_index calls _close_updateindex and then either > rescan_on_error or unlock_index as appropriate. Call sites have been updated > appropriately. > > The revert_helper proc, with its overlapping operations, is an example of a > call site that does not combine the close and unlock/rescan operations. The > checkout_index proc has been reworked to only call _close_updateindex, and > to call a functor supplied by the caller to captures any errors that occur. > revert_helper uses this to supply a lambda function that stashes the error > within the chord's body namespace, so that it can then separately call > rescan_on_error when the chord is completed (or unlock_index, if no error > was captured), which might be substantially after checkout_index encounters > its error. If it turns out that a rescan is called for, it is done once the > deletion is complete. > > This is the eighth revision of this change, which differs from the seventh > version in the following ways (most of which are in the second of the three > commits, to do with the status bar rework): > > * The bump of the Tcl/Tk dependency from 8.4 to 8.6 now takes place in the > third commit, where it is needed and whose commit message actually calls > it out. > > > * The show method in status_bar_operation has been renamed to restart, and > the meter is cleared. Also, the supplied message is set as the prefix for > future update calls. > > > * The call site for $status_operation show in blame.tcl has been > corresponding changed to $status_operation restart. > > > * A typo has been corrected in a comment. :-) Thanks for the quality contribution. Merged to 'master'. Will push it out soon. -- Regards, Pratyush Yadav
