bug#2678: 23.0.91; vc-next-action in vc-dir acts strangely when only adds are necessary

[Miles Bader <miles@gnu.org>]

On Sat, Mar 21, 2009 at 1:15 AM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> Given that you are familiar with git, the function to fix to get this
> working is the one liner `vc-git-register':
>
> (defun vc-git-register (files &optional rev comment)
>  "Register FILE into the git version-control system."
>  (vc-git-command nil 0 files "update-index" "--add" "--"))
...
> (vc-git-register "/tmp/zonk2/")

The obvious solution is to use "add" instead of "update-index --add".

[I tested it, it works.]

However, it'd be nice to ask whoever wrote this function originally
whether there was a reason for using "update-index" instead of "add",
given that vc.el apparently expects higher-level level functionality
(recursion) from the register hook.  I suppose update-index is the
more conservative choice, since it's officially "plumbing", but I'm
not aware of any problems with using the higher-level git-add in this
case.  [The git backend already uses "add" in other places too.]

Also, I wonder:

  (1) Given that vc-dir already has a list of files presented in the
directory listing, how come it doesn't give the backend that list,
instead of just the directory (having the backend do the recursion
seems more likely to yield unexpected results)?

   (2) Perhaps vc-dir it should do a "revert-buffer" (or something)
afterwards when it operations on a subdirectory or the whole
directory, as any operation with the backend doing the recursion may
change something other than what is displayed.  This is easy to see if
their were unregistered subdirectories with files -- doing "v" to
register a subdirectory adds all files in that directory, which vc-dir
hadn't displayed before, so currently "v" doesn't properly show them
afterwards (doing "g" shows them).

thanks,

-miles

-- 
Do not taunt Happy Fun Ball.