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 seventh revision of this change, which differs from the sixth
version in the following ways (all related to the second commit updating the
status bar):

 * The do_gitk and do_git_gui helper functions in git-gui.sh have been
   updated to use status bar operations to show their "Starting" messages.
   This eliminates the need for global variable starting_gitk_msg, and
   corrects an issue where do_git_gui would say it was starting gitk rather
   than git-gui by generalizing the localized message so the tool name can
   be injected. The time to the message being removed is reduced to 3.5
   seconds.

 * In blame.tcl, the comment on status_operation is made clearer.

 * In blame.tcl, when the status operation $cur_s string changes and there's
   already an existing status bar operation, its text is updated to match.

 * The choose_repository.tcl file has been updated to work with the new
   status bar model. There were some unnecessary complications that have
   been sorted out: The o_cons field is no longer overloaded in meaning, and
   the lifetimes of different status bar widgets is explicitly documented
   (one gets created and then destroyed during _do_clone2, and another
   separate one is greated during do_clone_checkout).

 * In choose_repository.tcl, there is a sequence of functions involved
   performing the checkout on the clone: _do_clone_checkout =>
   _readtree_wait => _postcheckout_wait => _do_clone_submodules =>
   _do_validate_submodule_cloning. The functions have been re-ordered in the
   source code to match the sequence in which they execute to improve
   clarity.

 * The two_line constructor in status_bar.tcl now also initializes
   completed_operation_count.

 * The start method on the status_bar class now no longer requires units to
   be supplied. If they are omitted, a blank string is used. It is assumed
   that the caller will not be calling update or update_meter in this
   circumstance (though nothing should break if they do, it just won't show
   any units).

git remote add logiclrd https://github.com/logiclrd/git.git
git fetch logiclrd git-gui-revert-untracked revision6
git diff d0d6593b42..3388407871

Jonathan Gilbert (3):
  git-gui: consolidate naming conventions
  git-gui: update status bar to track operations
  git-gui: revert untracked files by deleting them

 git-gui.sh                |  31 ++-
 lib/blame.tcl             |  24 +-
 lib/checkout_op.tcl       |  15 +-
 lib/choose_repository.tcl | 120 ++++++---
 lib/chord.tcl             | 160 ++++++++++++
 lib/index.tcl             | 523 ++++++++++++++++++++++++++++----------
 lib/merge.tcl             |  14 +-
 lib/status_bar.tcl        | 229 +++++++++++++++--
 8 files changed, 889 insertions(+), 227 deletions(-)
 create mode 100644 lib/chord.tcl

base-commit: b524f6b399c77b40c8bf2b6217585fde4731472a

Submitted-As:  Message-ID: pull.436.v6.git.1574929833.gitgitgadget@gmail.com
In-Reply-To:  Message-ID: pull.436.git.1572418123.gitgitgadget@gmail.com
In-Reply-To:  Message-ID: pull.436.v2.git.1573110335.gitgitgadget@gmail.com
In-Reply-To:  Message-ID: pull.436.v3.git.1573638988.gitgitgadget@gmail.com
In-Reply-To:  Message-ID: pull.436.v4.git.1573973770.gitgitgadget@gmail.com
In-Reply-To:  Message-ID: pull.436.v5.git.1574627876.gitgitgadget@gmail.com