Re: vc-dwim when nothing to commit

[Ted Zlatanov <tzz@lifelogs.com>]

On Sat, 18 Apr 2015 14:03:24 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Sat, 18 Apr 2015 06:22:37 -0400
>> 
EZ> Of course, bonus points for guessing the next command (not necessarily
EZ> "git push") given the previous one and the existence of telltale files
EZ> below .git/.  That would be much more in line with the spirit of
EZ> vc-next-action, IMO.
>> 
>> Right, so the history would be per repository and the very first initial
>> guess would be "git push" usually?  I would use that.
>> 
>> Unless there's a strong protest, I can try implementing a first cut of
>> this. I like that it fills a void, where you say "DWIM" after a Git
>> commit and VC goes "huh? go away!" :)

EZ> Please do, and TIA!  Don't be bothered by "strong protest", I don't
EZ> think we will see anything like that.

I tried this for myself.  Just adding a command prompt is trivial:

#+begin_src diff
diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index bb4dd60..a7af2ed 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -1175,7 +1175,8 @@ (defun vc-next-action (verbose)
 	(dolist (file files) (vc-checkout file)))
        (t
         ;; do nothing
-        (message "Fileset is up-to-date"))))
+        (message "Fileset is up-to-date")
+        (call-interactively 'shell-command))))
      ;; Files have local changes
      ((vc-compatible-state state 'edited)
       (let ((ready-for-commit files))
#+end_src

but it doesn't have its own history or context, doesn't prefill the
command, and the output is displayed in an annoying buffer.

I tried polishing the interaction but I kept coming back to "run eshell
or ansi-term and up-arrow brings up the last 'git push' in the current
directory" which is one keystroke for me.  That's because I really,
really want to know if `git push' fails, and which refs it failed to
push.  If there's a failure, I usually want to be in a shell and to fix
it.  If not, I don't want to see any popup buffers.

So maybe the best way to do it for Git is:

1) check to see if there's anything to push (local tracking branch is
ahead of remote).  If not, do nothing.

2) Else, prompt to "git push" and capture the output.  This piece should
have its own command history.

3) if there was any failure (I don't know if the return code is
sufficient to determine that), bring up eshell or ansi-term with the
failure output pre-inserted

Does that seem reasonable?  It's what I would want to use, but maybe
it's too heavy for most people.

Ted